Share cards cross-referencing to a different board open the board, but fail to open the card on the board #96
Labels
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Grandiras/Ponente#96
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Saying the card doesn't exist anymore on that board.
🤖 On it — follow along in the action run; the reply will link the full session transcript.
📜 Live transcript — updating every ~5 minutes while the task runs.
Fixed and pushed as
claude/issue-96.What was wrong
Following a link card to a card on a different board is the only case that broke, and the reason is that it changes two things at once — the route parameter and the
?card=query — which reach the reusedBoardPageas two separate parameter sets:/board/{id}.OnParametersSetAsynctears down the outgoing board's state and startsawait ReloadAsync().SupplyParameterFromQueryValueProvider, whoseLocationChangedhandler deliberately runs after the router's) then notifies the same component that the query changed — and that notification lands inside step 1's await on the database.At that moment the outgoing board is gone and the incoming board's cards have not arrived, so
OpenSharedCardanswered "that card isn't on this board", showed the toast, and — the part that made it unrecoverable — stripped?card=off the URL. When the load finished a few milliseconds later, its own call had nothing left to open. Apage.gototo the same link is a single parameter set, which is why the existing tests never saw it.The fix
src/Ponente.Kanban/Components/Pages/BoardPage.razor: a_loadingBoardflag, andOpenSharedCardrefuses to decide anything while a board is in flight — it leaves the query on the URL for the load's own call, which is the only one that can actually tell. Deliberately not a fetch-by-id or a redirect to the card's real board: "not here" still means not here, so a deleted card and a card on another board are still told the same thing.Also added: the e2e case in
tests/e2e/share.spec.js(follows a cross-board link from inside the app, creating and deleting its own second board the wayboards.spec.jsdoes), and a note inCLAUDE.mdnext to the existing?card=rules, since the two-parameter-sets ordering is the kind of thing that gets re-broken.No changelog entry: sharing itself is the unreleased
2.5.0entry (latest tag isv2.3.0), so no member has seen the broken behaviour, and that entry's "a shared link goes straight to the card it names" already promises what this restores.Verified
Reproduced and fixed against a real running instance — .NET 10 SDK + Postgres installed in this container, the app run in Development on
127.0.0.1:5000, driven with Playwright:element(s) not foundfor the target card's dialog), passes on the fixed one.dotnet build Ponente.sln— clean (one pre-existingCalendar.razorwarning).dotnet test Ponente.sln— 273 passed.share.spec.js board.spec.js boards.spec.js filter.spec.jslocally — 45 passed, 2 failed, both environmental and both confirmed to fail identically on unmodifiedmainhere: one asserts the origin is literallyhttp://localhost:8090/(my instance is on:5000), the other isboards.spec.js's 3 s calendar-paint deadline missed by this non-containerised dev-mode server. Nothing PDS-dependent (pds.spec.js,access.spec.js) was run — there is no PDS container in this environment.⏱ 15m 23s · 82 turns · tokens: 139.5k in / 38.2k out (+10044.4k cache-read)
📜 Full session transcript
→ Opened PR: #97