Skip to content

Upstream give-back backlog (hold until V2 merges upstream) #276

New issue
New issue
Open
Open
Upstream give-back backlog (hold until V2 merges upstream)#276
Labels
enhancementNew feature or request

Description

@Jacksondr5
Jacksondr5
opened on Sep 24, 2026

Fixes and improvements J5 carries that belong upstream. We hold them while V2 (pingdotgg#2829) is still under heavy construction, then offer them once it settles and merges. Check this list at every upstream advance and remove items upstream fixes on its own.

Offered upstream

A daily check reads this list and reports new activity. Add a line here whenever we post something upstream.

When we offer a fix, prepare the PR and add "Watcher armed" to the item's line, with the prepared branch and whether Jackson has approved the PR text. The watcher (~/.local/share/giveback-watch/watch.sh on openclaw, every 15 minutes, as the machine participant machine:giveback-watch) messages the give-back thread when an armed item gets new activity, so we can open the PR as soon as a maintainer agrees.

Not yet offered

Activity

  1. Jacksondr5
    added
    enhancementNew feature or request
    on Sep 24, 2026
  2. Jacksondr5
    added 2 commits that reference this issue on Sep 24, 2026

    refactor(web): adopt upstream's steer and queue UI, retiring the trut…

    bfe9dce

    docs(fork): retire cases 27 and 29, link the merge process, route pat…

    24bc5ea

  3. Jacksondr5 commented on Sep 24, 2026

    @Jacksondr5
    Jacksondr5
    on Sep 24, 2026
    OwnerAuthor

    More upstream candidates from the #262 live pass (evidence). Re-check them against upstream before offering:

    • A server restart cancels the running turn silently. The cancelled turn has no marker, and it shows the wrong duration ("Worked for 479ms" for about 24 s of work). While only a held queued run remains, the sidebar says "Working".
    • "New thread on " opens a draft on the worktree's temporary branch name (t3code/<id>), not the chosen branch.
    • A repo with no remote shows "From origin/master" as the base branch. Dropped 2026-10-24 (Jackson). fix(server): new worktrees fetch their base branch's own remote pingdotgg/t3code#21032 (merged 2026-10-19) reworked this: worktrees fetch the base branch's own remote and fall back to the local branch, and the label became "From (remote)", left unconditional on purpose ("Only the server can determine a local branch's configured remote"). What remains (no-remote repos, unpushed branches) is rare and harmless, and upstream just chose that wording, so it isn't worth raising.

    Parked 2026-10-24: the restart-marker and "New thread on " items. Both look fixed or reworked on upstream main 80455376f0 (the sidebar Working status by PR pingdotgg#17028; the branch handling reads right in code). Re-test on current upstream before offering either.

  4. Jacksondr5 commented on Sep 25, 2026

    @Jacksondr5
    Jacksondr5
    on Sep 25, 2026
    OwnerAuthor

    Give-back candidate (Jackson, 2026-09-25): on environment-wide settings pages (upstream's Providers, and J5's Personas and Skills catalog), the new settings scope line still says "Applying settings for " when a project is selected, even though those settings can't be scoped to a project (only keys in PROJECT_SCOPED_SERVER_SETTING_KEYS can). Suggest that upstream hide or disable the project picker, or reword the line, on pages whose settings are environment-wide.

    Dropped 2026-10-24 (Jackson). The Providers page is now partly per-project (providers can be switched per project, pingdotgg#17879), so it is no longer a clean example. What remains (Diagnostics, and J5's own Personas and Skills pages) is cosmetic.

  5. Jacksondr5 commented on Sep 29, 2026

    @Jacksondr5
    Jacksondr5
    on Sep 29, 2026
    OwnerAuthor

    Added: Dead agent-device daemon reused by the device hub (#364, PR #369). LocalDeviceHost.ensureAgentReady returns the cached agent-device endpoint without a health check, so after the daemon exits every device_open hands out a dead --config. The fix probes /health before reuse and restarts the daemon. Still present on upstream/main.

    🤖 Generated with Claude Code

  6. Jacksondr5 commented on Sep 30, 2026

    @Jacksondr5
    Jacksondr5
    on Sep 30, 2026
    OwnerAuthor

    Update: the dead agent-device daemon fix (#364, #369) was closed without merging, so J5 isn't carrying it. It's no longer part of this give-back list.

    Posted by an AI agent on Jackson's behalf.

  7. Jacksondr5 commented on Oct 5, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 5, 2026
    OwnerAuthor

    Give-back candidate: A hung simctl breaks device listing, behind a generic error. Seen 2026-10-04 on Jackson's Mac, after CoreSimulatorService had been up for about 2 days and stopped answering. Every simctl call hung, including simctl help. Restarting the service fixed it.

    What the person saw:

    • The panel showed only "Device list failed: Could not communicate with device support. Try refreshing devices." The real cause, simctl not answering, never reached the person.
    • The iOS device list kept emptying and refilling. On refreshes where simctl failed instead of hanging, the hub returned simulators: [] with errors. refresh in DeviceService.ts replaced the host's devices with that empty list, then the next good call brought them back.
    • Stuck simctl list devices --json processes piled up, one every refresh. We counted 15, some orphaned (ppid 1) by earlier hub runs.

    Where it belongs:

    • expo-device-hub (expo/expo-device-hub): execSimctl calls execFile("xcrun", ["simctl", ...]) with no timeout, so a wedged CoreSimulator holds /api/devices open indefinitely. This is still the case in 0.12.0, the version upstream pins as of upstream/main a1d9d72aef. Suggest a timeout that kills the child, and an error saying simctl did not respond.
    • T3 Code (apps/server/src/device/DeviceService.ts and the request_failed text in packages/contracts/src/device.ts, unchanged on upstream/main a1d9d72aef):
      • hubJson maps a timeout, a bad status and a decode failure all to the same request_failed message. Telling a timeout apart ("The device hub did not answer within 15 s") would have pointed straight at the simulator service.
      • When the hub's list comes back empty and carries errors, consider keeping the host's last known devices, with the error as detail, instead of showing none.

    J5 carries no fix for this. The person-side fix is killall -9 com.apple.CoreSimulator.CoreSimulatorService (with Simulator.app quit). Re-check against upstream and expo-device-hub before offering.

    Posted by an AI agent on Jackson's behalf.

    Partly offered upstream 2026-10-25: pingdotgg#25248 shows the hub's error detail. The timeout message, the emptying list and the expo-device-hub timeout are drafted, not yet filed.

  8. Jacksondr5 commented on Oct 8, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 8, 2026
    OwnerAuthor

    Candidate: the welcome wizard forgets the folder selection when you jump back to a stage by name

    Not posted upstream. Recorded here for the give-back pass.

    • What happens: in the import step, change which folders are selected (for example "Select none", then tick one). Click the Providers stage in the header, then Continue. The selection is back to the defaults and the one you ticked is unticked.
    • Who hits it: only someone who jumps between stages by clicking a stage name. Going straight through the wizard never triggers it, and there is no Back button between those two stages.
    • Likely cause, not confirmed against upstream's source: the selected paths are local state inside the import step, which unmounts when the stage changes.
    • Why this is upstream's: J5's wizard is upstream's components/onboarding/WelcomeWizard.tsx since refactor(web): onboarding goes back to upstream's three stages #457, apart from branding and the "Providers" wording (FORK.md case 39). J5's older wizard kept the selection in its own import session, which refactor(web): onboarding goes back to upstream's three stages #457 removed.
    • Evidence: a tester reproduced it on 2026-10-04 on refactor(web): onboarding goes back to upstream's three stages #457's head against its base, with paired screenshots.
    • Not checked: whether upstream main still behaves this way, and whether upstream already tracks it.

    Offered upstream 2026-10-25: pingdotgg#24719 (reproduced on upstream 90c455ff8f).

  9. Jacksondr5 commented on Oct 10, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 10, 2026
    OwnerAuthor

    Removed: revoking a client does not close the sockets it already has open. Fixed upstream by pingdotgg#17370 (merged 2026-10-09): the /ws route now closes a session's socket when it is revoked or expires. J5 picks it up at the next upstream advance; until then J5's copy still has the gap.

    Posted by an AI agent on Jackson's behalf.

  10. Jacksondr5 commented on Oct 12, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 12, 2026
    OwnerAuthor

    Candidate: a server's name cannot be set, so two servers on one machine report the same name

    Not posted upstream. Recorded here for the give-back pass.

    Posted by an AI agent on Jackson's behalf.

    Dropped 2026-10-30 (Jackson). Not worth offering: the upstream request (issue pingdotgg#13057, now Ideas discussion pingdotgg#23118, 10 upvotes) asks for much more (account-wide names, rename/restore in the UI, deregistering stale environments), and pingdotgg#18924 (PixPMusic, open) already adds a persisted host-name setting in Settings → Sharing & access, editable from mobile. If pingdotgg#18924 lands, J5 can retire D32 (J5CODE_SERVER_NAME), since each J5 server has its own home and so its own setting.

  11. Jacksondr5 commented on Oct 12, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 12, 2026
    OwnerAuthor

    Candidate: node --watch src/bin.ts restarts the dev server when another pnpm worktree installs (not posted upstream): on Linux a bare --watch watches about 1,200 loaded files under node_modules/.pnpm that pnpm hardlinks from its shared store, so a second worktree's install or removal changes their link count and restarts the server; J5 narrowed it to --watch-path=src --watch-path=../../packages in #550 (issue #544, FORK.md case 66), measured there, and upstream main was not checked for an existing fix or issue.

  12. Jacksondr5 commented on Oct 12, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 12, 2026
    OwnerAuthor

    Give-back candidate from #551 (live-test home generator, #546): ask upstream to export a replay seam from apps/server/src/orchestration-v2/testkit.

    Today the function that replays one fixture variant, runFixtureProvider, is private to OrchestratorReplayFixtures.integration.test.ts, and so is the driver-to-harness lookup beside it. J5's generator carries an adapted copy (about 70 lines, replayFixture in apps/server/src/j5/test-support/liveTestHome.ts).

    A seam that would remove the copy: one exported function, roughly replayFixture({ fixture, variant, databaseLayer, projectId, cwd, clockStartMs }), which the test file would call too. The copy differs from the original in four ways: a file database, a caller-supplied project id (the fixture allocates one that nothing creates), a caller-supplied cwd, and a settable clock (replays otherwise start in 1970). The fork and merge-back scenarios live in their own test files and are not in ORCHESTRATOR_REPLAY_FIXTURES, so they are out of reach either way.

    Dropped 2026-10-24 (Jackson). Upstream PR pingdotgg#22717 (2026-10-21) now exports most of this: runReplayFixture in testkit/ProviderReplayFixtures.ts, and each provider's replay harness from its adapter testkit. At the next upstream advance, shrink J5's copy to glue around those instead of asking upstream.

  13. Jacksondr5 commented on Oct 12, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 12, 2026
    OwnerAuthor

    Give-back candidate from the live-testing work (#546, PR #556), 2026-10-12: vp run dev --share can replace another server's tailscale serve mapping.

    • scripts/lib/dev-share.ts clears whatever is mapped on the web port before serving it, and on exit the mapping is removed.
    • scripts/dev-runner.ts picks a worktree's web port from 5734 to 8733 by hashing the path and probes only loopback for a free port, so a port that is in use only as a tailnet HTTPS listener looks free.
    • So a dev server whose web port equals a port another server already publishes on the tailnet replaces that mapping on start and removes it on exit. On the J5 dev host the installed server publishes on 8444, which is inside that range.

    Suggested change upstream: do not clear a mapping whose target is a different local port, or refuse to share when the port already carries a mapping this process did not make. J5's setup-agent-live-test --for-dev guards against it in its own code; upstream's files are not edited.

  14. Jacksondr5 commented on Oct 12, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 12, 2026
    OwnerAuthor

    Removed: a queued message from a capped caller runs at the receiver's raised modes. Jackson, 2026-10-18: not offered upstream. It is a narrow edge case. The person has to raise the thread's modes deliberately while the message waits in the queue in plain view, and then want only that one message held back. (Found in #498 / PR #560.)

    Posted by Claude Opus 5.5, an AI agent, on Jackson's behalf.

  15. Jacksondr5 commented on Oct 18, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 18, 2026
    OwnerAuthor

    Offered upstream on 2026-10-17:

    Deferred for Jackson to review: the t3 link (pingdotgg#14875) and the service launcher (pingdotgg#19652). Not posting on the server name (pingdotgg#18924), because we have nothing new to add.

    Posted by Claude Opus 5.5, an AI agent, on Jackson's behalf.

  16. Jacksondr5 commented on Oct 18, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 18, 2026
    OwnerAuthor

    Checked against the 2026-10-17 upstream advance (#634, upstream nightly 70d60e03a7):

  17. Jacksondr5 commented on Oct 19, 2026

    @Jacksondr5
    Jacksondr5
    on Oct 19, 2026
    OwnerAuthor

    Filed upstream: pingdotgg#22024. Web and desktop offer no retry while an environment is reconnecting, and the wait grows to five minutes. J5's fix is #667 and #668 (register D37, FORK.md temporary patch). The issue offers a PR if upstream wants one; drop the patch when upstream ships its own.

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

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions