{"version":"2.1.248","anchor":"remote-sessions-can-wait-for-an-auth-token-instead-of-errori","canonical_anchor":"remote-sessions-can-wait-for-an-auth-token-instead-of-errori","heading":"Remote sessions can wait for an auth token instead of erroring out","tier":"soon","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/remote-sessions-can-wait-for-an-auth-token-instead-of-errori","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Remote sessions can wait for an auth token instead of erroring out\n\nRemote connections can wait for a late auth token, but only when an option asks for it.\n\n**What**\n\nThe remote connection layer gained a `rereadMissingAuthHeaders` option. With it set, starting up without an auth token no longer fails: connection setup and worker startup are deferred behind a promise that re-reads the token, and the resume timing is re-based once it arrives. Without the option, the old immediate error path is unchanged.\n\n**Details**\n\n- The deferred path logs \"[remote-io] No session ingress token available yet, will re-read\" instead of the old \"[remote-io] No session ingress token available\" error.\n- Both worker initialization and transport connect wait on the re-read.\n\n**Evidence**\n\n`[remote-io] No session ingress token available yet, will re-read`\n\n- Area: Sessions\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}