Skip to content

app.orbit.global fails to decode responses from a stock @orbit/station-v0.7.0 (Candid "expect type null") — dashboard + request submit both broken #643

Description

@eladmint

On a mainnet Station pinned to the official @orbit/station-v0.7.0 release, the hosted wallet at app.orbit.global can no longer decode the station's responses — the Dashboard fails to load and submitting a Change-canister / Install request fails, both with the same Candid decode error.

Environment

  • Station: sffmj-7aaaa-aaaai-rapga-cai, on-chain module hash 0x3635057d8795fb3218cac110f21e514941368f917576ee05004fa72cc820e7bebyte-identical to the official @orbit/station-v0.7.0 release artifact (verified by sha256 of a fresh download from this repo's releases).
  • Upgrader: scek5-syaaa-aaaai-rapgq-cai = official @orbit/upgrader-v0.3.0.
  • Station health_status()Healthy on-chain.
  • Client: app.orbit.global (hosted), fresh incognito session (rules out stale cached JS).

Symptom

Both the Dashboard and a "Change canister → Install (mode = Upgrade)" submit fail. Browser console (agent-js Candid decoder):

Failed to load data Error: type mismatch: type on the wire rec_268, expect type null
Failed to submit change canister request Error: type mismatch: type on the wire rec_1966, expect type null
    at qn.checkType (ic-libs-*.js)
    at qn.decodeValue (ic-libs-*.js)
    at ei.decodeValue (ic-libs-*.js)
    ...

(also seen: rec_291.) The install request is correctly configured — mode Upgrade, a valid gzipped wasm module, checksum shown — and the failure is in decoding the station's response, not in the request itself.

What we checked ourselves before filing

  • The station is stock v0.7.0 (hash match above), so it isn't a modified/broken deploy on our side.
  • We looked for a Candid interface drift between the tag and main: compare @orbit/station-v0.7.0...main shows no station API change (only a Rust derive addition), and the wallet package is still 0.7.0. So this does not appear to be the frontend expecting a newer station field — it reads as a client-side decode regression in the current hosted app.orbit.global build against a v0.7.0 station.

Questions

  1. Is this a known issue with the currently-deployed app.orbit.global against @orbit/station-v0.7.0 stations?
  2. What's the recommended path for a station pinned at v0.7.0 — wait for a hosted-frontend fix, or is a station upgrade required (and if so, to which release)?

Happy to provide more console/network detail. Thanks!

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions