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 0x3635057d8795fb3218cac110f21e514941368f917576ee05004fa72cc820e7be — byte-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
- Is this a known issue with the currently-deployed
app.orbit.global against @orbit/station-v0.7.0 stations?
- 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!
On a mainnet Station pinned to the official
@orbit/station-v0.7.0release, the hosted wallet atapp.orbit.globalcan 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
sffmj-7aaaa-aaaai-rapga-cai, on-chain module hash0x3635057d8795fb3218cac110f21e514941368f917576ee05004fa72cc820e7be— byte-identical to the official@orbit/station-v0.7.0release artifact (verified by sha256 of a fresh download from this repo's releases).scek5-syaaa-aaaai-rapgq-cai= official@orbit/upgrader-v0.3.0.health_status()→Healthyon-chain.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):
(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
main:compare @orbit/station-v0.7.0...mainshows no station API change (only a Rustderiveaddition), and the wallet package is still0.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 hostedapp.orbit.globalbuild against a v0.7.0 station.Questions
app.orbit.globalagainst@orbit/station-v0.7.0stations?Happy to provide more console/network detail. Thanks!