Open shifts follow-up: keep post keys across a reload, clear them on account deletion

Merged
BI
1mo ago
+281-9

User description

Summary

Before: the post key that stops a retried gap post creating a second open shift lived only in page memory. If the answer was lost and the person reloaded the page before retrying, a new key was made and a duplicate shift could still be posted. Saved post keys also kept naming a person after their account was deleted.

After: the post page keeps each date's key in session storage for up to 24 hours, so a retry after a reload sends the same key. Signing in as someone else clears the stored keys. In the database, roster_open_post_keys.posted_by now references auth.users with on delete set null, so deleting an account clears the name from its post keys.

How: new migration 20261015181500_roster_open_post_keys_posted_by_fk.sql nulls any posted_by with no matching user, then adds the foreign key. schema.sql, the drift manifest and the migration seal are updated (the seal adds one new entry only). New open-shifts-post-keys.ts handles storage with every call guarded. The roster alerts test now checks the exact assignment read for a new post, and the SQL behaviour test proves account deletion clears the key's name.

Areas touched: Personal practice, Data platform and access

RAG impact: no retrieval behaviour change, roster only.

Verification

  • check:migration-immutability: "312 shipped migrations unchanged".
  • Vitest: open-shifts post retry, roster alerts and roster team API tests, 38 passed. Typecheck and eslint clean on the changed files (earlier run), prettier clean.
  • Not run locally: the Postgres 17 drift manifest regeneration and browser tests. CI's migration replay and drift freshness checks are the proof.

Risk and rollout

  • Database migration. Merging applies it to the live database within seconds. Merge only inside the approved window, with the owner's named yes to this specific change. Keep this PR as a draft until then.
  • Rollback: a forward migration dropping roster_open_post_keys_posted_by_fkey.

Notes

  • No patient data. Work mode roster data only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LuYbdEGXeMntVA9KMgtAEx

Generated by Claude Code

Summary by cubic

Keeps open-shift post keys in session storage so a retry after a reload never creates a duplicate shift, clears those keys on account change or deletion, and stops a post when the signed-in account changes mid-run.

  • Post keys survive reloads for up to 24 hours and are dropped once the post is confirmed, either by the server's answer or by the refreshed list showing the shift went live.
  • Keys are tied to the signed-in person; signing out clears them, another account never reuses them, and a mid-post account change stops further requests while keeping the dates that already went live and naming them in the stop message.
  • A sealed database migration makes roster_open_post_keys.posted_by reference auth.users with on delete set null, matching roster_open_shifts.posted_by; the seal hash is added to .gitleaksignore since the filename contains "keys" and the value reads as a key.
  • open-shifts-post-keys.ts guards all storage access so the page still works when storage is blocked.

Summary by CodeRabbit

  • Bug Fixes
    • Open-shift posts now retain retry keys across page reloads, helping prevent duplicate posts when a submission gets no response. Keys are cleared once the post is confirmed.
    • Retry keys are cleared when switching accounts, and related records are handled safely when an account is deleted.
    • If the signed-in account changes while a post is in progress, further requests stop and the results aren’t applied.

CodeAnt-AI Description

Keep open-shift retry keys across reloads and clear them when no longer needed

What Changed

  • Retrying an open-shift post after a page reload reuses its saved key for up to 24 hours, preventing a lost response from creating a duplicate shift.
  • Keys are cleared when a post is confirmed and are not reused by another person signing in on the same tab.
  • Deleting an account clears that person’s ID from their saved post keys.

Impact

✅ Fewer duplicate open shifts after reloads
✅ Safe retries after lost post responses
✅ No deleted-account IDs on saved post keys

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.