Repository navigation
fix(app-space): prefer COMPLETED record when a task has multiple TaskRecords - #2938
Merged
Merged
Conversation
release: promote event display track-grouping fix (DEV \u2192 main)
release 1.41.5: event-display track grouping + counting fixes
…Records getAppSpaceProgress + getEventProgress collapsed a user's TaskRecords to one per (taskType, taskLegacyId) with a plain last-write-wins loop over an UNORDERED query. A user who RESET a tutorial holds both a COMPLETED row and SUPERSEDED row(s) for it (#600 has-ever-completed). Whichever the query returned last won nondeterministically — when a SUPERSEDED/reset row landed last, a genuinely completed tutorial rendered as not-done. Reported: app-space showing "2 of 4" ABAP tutorials complete after the reporter had reset + re-completed them, while other (never-reset, single-record) tracks were fine. Add buildRecordMap(userRecords): collapse deterministically, preferring COMPLETED > SUPERSEDED > other, ties broken by latest completionDate. Use it at both call sites (developer-service.js:603, :714). The #2866 in-window downgrade still applies to whichever record survives. Verified: running the real getAppSpaceProgress resolution against PROD data for the reporter's ABAP track now returns 4/4 COMPLETED deterministically. New unit test (test/lib/build-record-map.test.js) covers status preference + date tie-break + per-key separation.
Contributor
Author
|
Confirmed this fix also covers a second report: the first CAP tutorial ("Set up a self-contained development environment for CAP Node.js", lid 10000030) showed complete in its own view but app-space blocked progress. Reporter's records for it:
Same mechanism — the unordered last-write-wins map could keep the SUPERSEDED reset row. |
This was referenced Oct 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
getAppSpaceProgress+getEventProgresscollapsed a user's TaskRecords to one per(taskType, taskLegacyId)with a plain last-write-wins loop over an unordered query. A user who reset a tutorial holds both a COMPLETED row and SUPERSEDED row(s) (#600 has-ever-completed). Whichever the query returned last won nondeterministically — a SUPERSEDED/reset row landing last made a completed tutorial render as not-done.Reported: app-space showed "2 of 4" ABAP tutorials complete after the reporter reset + re-completed them; never-reset single-record tracks were fine.
Fix:
buildRecordMap(userRecords)collapses deterministically — preferCOMPLETED > SUPERSEDED > other, ties broken by latestcompletionDate. Used at both call sites. The #2866 in-window downgrade still applies to the surviving record.Verification
getAppSpaceProgressresolution against PROD data for the reporter's ABAP track → 4/4 COMPLETED, deterministic.test/lib/build-record-map.test.js(status preference, date tie-break, per-key separation). 29 tests pass locally.Test plan