This follow-up keeps the one-shot Electron metadata fallback retryable after transient request failures or live stream updates. Pool limits remain daemon-authoritative; this does not add polling. The shared-state documentation now explains the Electron-only metadata read and event-triggered retry behavior.
The initial configurability metadata fix and its E2E readiness regression are part of #751 so the base feature PR is independently usable and greenable. This PR retains only the distinct retry-after-stream-loss fix and its documentation.
Verification
npm --prefix apps/sisyphus run typecheck
npm --prefix apps/sisyphus test (235 passed)
npm --prefix apps/sisyphus run build
make lint
actionlint
gofmt
git diff --check
make cover attempted locally; Kubo/IPFS integration cases cannot run because ipfs is not installed while SISYPHUS_REQUIRE_KUBO is set. The required full coverage gate is running in CI.
## Summary
This follow-up keeps the one-shot Electron metadata fallback retryable after transient request failures or live stream updates. Pool limits remain daemon-authoritative; this does not add polling. The shared-state documentation now explains the Electron-only metadata read and event-triggered retry behavior.
The initial configurability metadata fix and its E2E readiness regression are part of #751 so the base feature PR is independently usable and greenable. This PR retains only the distinct retry-after-stream-loss fix and its documentation.
## Verification
- `npm --prefix apps/sisyphus run typecheck`
- `npm --prefix apps/sisyphus test` (235 passed)
- `npm --prefix apps/sisyphus run build`
- `make lint`
- `actionlint`
- `gofmt`
- `git diff --check`
- `make cover` attempted locally; Kubo/IPFS integration cases cannot run because `ipfs` is not installed while `SISYPHUS_REQUIRE_KUBO` is set. The required full coverage gate is running in CI.
Part of #741.
/cc @rvnminers-A-and-N
I read the latest diff and preserved your distinct retry-after-stream-loss change. To fix the actual disabled-controls E2E failure in #751, I moved the first commit (metadata preservation plus enabled-control E2E readiness) into #751. This PR is now rebased onto that refreshed parent and narrowed to the second commit, which clears the fallback guard after failure/live updates. The branch and description now reflect that split; Austin remains requested as reviewer.
I read the latest diff and preserved your distinct retry-after-stream-loss change. To fix the actual disabled-controls E2E failure in #751, I moved the first commit (metadata preservation plus enabled-control E2E readiness) into #751. This PR is now rebased onto that refreshed parent and narrowed to the second commit, which clears the fallback guard after failure/live updates. The branch and description now reflect that split; Austin remains requested as reviewer.
/cc @rvnminers-A-and-N
Branch maintenance: rebased the retry-after-stream-loss change onto the current #751 head, resolving the stale-base conflict. Added a README note explaining that Electron-only pool-limit metadata is retried after stream/domain recovery and that this is event-triggered, not polling. Local renderer tests (235), typecheck, production build, make lint, actionlint, gofmt and diff checks pass. make cover was attempted but cannot pass locally because ipfs is absent while SISYPHUS_REQUIRE_KUBO is set; the required full coverage run remains in CI. Austin reviewer request is preserved. /cc @rvnminers-A-and-N
Branch maintenance: rebased the retry-after-stream-loss change onto the current #751 head, resolving the stale-base conflict. Added a README note explaining that Electron-only pool-limit metadata is retried after stream/domain recovery and that this is event-triggered, not polling. Local renderer tests (235), typecheck, production build, make lint, actionlint, gofmt and diff checks pass. `make cover` was attempted but cannot pass locally because `ipfs` is absent while `SISYPHUS_REQUIRE_KUBO` is set; the required full coverage run remains in CI. Austin reviewer request is preserved. /cc @rvnminers-A-and-N
Thanks Lior. The intent makes sense, and CI is green on 3f3e2ba. A couple of things I noticed while tracing it.
The README says the metadata read is retried on the next recovery or update. In the code, a stream event only clears fallbackRequested; the actual retry happens in reconnect, which runs when the stream drops. So if the first getPoolLimits fails but the stream is healthy, managed stays false and the Restart node button stays hidden until something disconnects. Retrying from the data handler while managed/configurable are still unknown would match the docs.
Also, since finally now clears the guard, every disconnect re-reads, even after a successful load. A node restart will toast "load failed" at each backoff step, and #752's card does the same. Could reconnect-time reads skip when the metadata is already known, or fail silently?
Since this is 7 lines on top of #751 and carries 751's commits, would it be easier to fold it into 751 before that gets rebased onto dev?
Thanks Lior. The intent makes sense, and CI is green on 3f3e2ba. A couple of things I noticed while tracing it.
The README says the metadata read is retried on the next recovery or update. In the code, a stream event only clears `fallbackRequested`; the actual retry happens in `reconnect`, which runs when the stream drops. So if the first `getPoolLimits` fails but the stream is healthy, `managed` stays false and the Restart node button stays hidden until something disconnects. Retrying from the data handler while `managed`/`configurable` are still unknown would match the docs.
Also, since `finally` now clears the guard, every disconnect re-reads, even after a successful load. A node restart will toast "load failed" at each backoff step, and #752's card does the same. Could reconnect-time reads skip when the metadata is already known, or fail silently?
Since this is 7 lines on top of #751 and carries 751's commits, would it be easier to fold it into 751 before that gets rebased onto dev?
Refreshed this follow-up onto the current #751 head. The metadata read now retries when a healthy POOL_LIMITS snapshot arrives after startup failed, and it only fetches again while management metadata is still unknown. Reconnect/update retries are silent, so repeated backoff no longer produces a toast per attempt. The existing docs now match the event-triggered retry behavior. Renderer tests, typecheck, and production build pass locally; fresh CI is running.
Refreshed this follow-up onto the current #751 head. The metadata read now retries when a healthy POOL_LIMITS snapshot arrives after startup failed, and it only fetches again while management metadata is still unknown. Reconnect/update retries are silent, so repeated backoff no longer produces a toast per attempt. The existing docs now match the event-triggered retry behavior. Renderer tests, typecheck, and production build pass locally; fresh CI is running.
/cc @rvnminers-A-and-N
I refreshed this on the new #751 root and reconciled the metadata behavior: stream snapshots remain non-editable until management metadata arrives; metadata reads retry on a healthy stream event if startup raced the daemon, then stop once known. Reconnect reads are silent and skipped after a successful metadata read, so an outage does not produce a toast at every backoff step. #752 already follows the same pattern for location discovery.
I refreshed this on the new #751 root and reconciled the metadata behavior: stream snapshots remain non-editable until management metadata arrives; metadata reads retry on a healthy stream event if startup raced the daemon, then stop once known. Reconnect reads are silent and skipped after a successful metadata read, so an outage does not produce a toast at every backoff step. #752 already follows the same pattern for location discovery.
/cc @rvnminers-A-and-N
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
rvnminers-A-and-N
Summary
This follow-up keeps the one-shot Electron metadata fallback retryable after transient request failures or live stream updates. Pool limits remain daemon-authoritative; this does not add polling. The shared-state documentation now explains the Electron-only metadata read and event-triggered retry behavior.
The initial configurability metadata fix and its E2E readiness regression are part of #751 so the base feature PR is independently usable and greenable. This PR retains only the distinct retry-after-stream-loss fix and its documentation.
Verification
npm --prefix apps/sisyphus run typechecknpm --prefix apps/sisyphus test(235 passed)npm --prefix apps/sisyphus run buildmake lintactionlintgofmtgit diff --checkmake coverattempted locally; Kubo/IPFS integration cases cannot run becauseipfsis not installed whileSISYPHUS_REQUIRE_KUBOis set. The required full coverage gate is running in CI.Part of #741.
/cc @rvnminers-A-and-N
I read the latest diff and preserved your distinct retry-after-stream-loss change. To fix the actual disabled-controls E2E failure in #751, I moved the first commit (metadata preservation plus enabled-control E2E readiness) into #751. This PR is now rebased onto that refreshed parent and narrowed to the second commit, which clears the fallback guard after failure/live updates. The branch and description now reflect that split; Austin remains requested as reviewer.
/cc @rvnminers-A-and-N
Branch maintenance: rebased the retry-after-stream-loss change onto the current #751 head, resolving the stale-base conflict. Added a README note explaining that Electron-only pool-limit metadata is retried after stream/domain recovery and that this is event-triggered, not polling. Local renderer tests (235), typecheck, production build, make lint, actionlint, gofmt and diff checks pass.
make coverwas attempted but cannot pass locally becauseipfsis absent whileSISYPHUS_REQUIRE_KUBOis set; the required full coverage run remains in CI. Austin reviewer request is preserved. /cc @rvnminers-A-and-NThanks Lior. The intent makes sense, and CI is green on 3f3e2ba. A couple of things I noticed while tracing it.
The README says the metadata read is retried on the next recovery or update. In the code, a stream event only clears
fallbackRequested; the actual retry happens inreconnect, which runs when the stream drops. So if the firstgetPoolLimitsfails but the stream is healthy,managedstays false and the Restart node button stays hidden until something disconnects. Retrying from the data handler whilemanaged/configurableare still unknown would match the docs.Also, since
finallynow clears the guard, every disconnect re-reads, even after a successful load. A node restart will toast "load failed" at each backoff step, and #752's card does the same. Could reconnect-time reads skip when the metadata is already known, or fail silently?Since this is 7 lines on top of #751 and carries 751's commits, would it be easier to fold it into 751 before that gets rebased onto dev?
Refreshed this follow-up onto the current #751 head. The metadata read now retries when a healthy POOL_LIMITS snapshot arrives after startup failed, and it only fetches again while management metadata is still unknown. Reconnect/update retries are silent, so repeated backoff no longer produces a toast per attempt. The existing docs now match the event-triggered retry behavior. Renderer tests, typecheck, and production build pass locally; fresh CI is running.
/cc @rvnminers-A-and-N
I refreshed this on the new #751 root and reconciled the metadata behavior: stream snapshots remain non-editable until management metadata arrives; metadata reads retry on a healthy stream event if startup raced the daemon, then stop once known. Reconnect reads are silent and skipped after a successful metadata read, so an outage does not produce a toast at every backoff step. #752 already follows the same pattern for location discovery.
/cc @rvnminers-A-and-N