fix: improve snapshot compare and saved jobs handling (#71, #74, #75, #82) - #120
Conversation
…82) - Fix snapshot comparison logic in SnapshotCenterScreen - Correct saved jobs metadata persistence - Improve job activity status display - Handle edge cases in snapshot diff rendering Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d991addca2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| records.push(...(page.records ?? [])); | ||
| while (page.nextRecordsUrl && records.length < 100_000) { | ||
| page = await props.sf.queryMore(page.nextRecordsUrl, props.tabId); | ||
| page = await props.sf.queryMore(page.nextRecordsUrl); |
There was a problem hiding this comment.
When the live query returns nextRecordsUrl, this continuation switches from CROSS_ORG_QUERY to SF_QUERY_MORE without a tabId. The latter resolves authentication from a Salesforce tab, so requests from the full-page extension can fail on page two; even if a tab is resolved, it may belong to a different org than targetOrgId. Live comparisons for multi-page results therefore fail or continue against the wrong org. Add a cross-org query-more path that retains targetOrgId for every page.
Useful? React with 👍 / 👎.
| const delta = Math.abs(snapshot.capturedAt - run.startedAt); | ||
| if (delta < bestDelta) { | ||
| bestDelta = delta; | ||
| bestId = snapshot.id; | ||
| } | ||
| } |
There was a problem hiding this comment.
When retention has pruned an older run's snapshot, this unconditionally assigns that run the nearest surviving snapshot from the same schedule, regardless of how far apart their timestamps are. Consequently every historical run appears to have an “Open result” even when its result was deleted, and the link leads users to an unrelated run's snapshots. Match the run's capture timestamp (the scheduler records capturedAt from the same startedAt value) or retain a suitably strict maximum delta.
Useful? React with 👍 / 👎.
| ): SavedJob[] { | ||
| const byId = new Map(existing.map(job => [job.id, job])); | ||
| const tombstones = new Set(deletedLegacyIds); | ||
| const byId = new Map(existing.filter(job => !tombstones.has(job.id)).map(job => [job.id, job])); |
There was a problem hiding this comment.
After a migrated job is deleted, its ID remains tombstoned. If the user later imports a portable backup containing that same ID, importFile sees no collision and reports a successful import, but this filter removes the restored job the next time the screen mounts. Tombstones should suppress only regeneration from the legacy template/schedule arrays, or importing the job should clear/replace its tombstone.
Useful? React with 👍 / 👎.
1 participant
Summary
Improves snapshot comparison logic and saved jobs persistence.
Issues Fixed
Changes
🤖 Generated with Claude Code