Skip to content
RepStackReviews, organized.Open RepStack

Help & transparency

Incident reports

A clear record of what happened, what it affected, and what we did to put it right.

Last updated · Dates in UTC

About this record

Documented issues affecting use of RepStack, with their impact and fixes. Internal testing and maintenance records are kept separately. This is a manually updated history, not live service status. Older entries use recorded fix dates where the original incident timing is unknown.

“Resolved” includes recorded recovery evidence. “Fix recorded” identifies a documented correction where the full production recovery record is unavailable.

September 202610 reports

Fix recordedAccount access

Email changes could show incorrect confirmations and account details

An email change confirmed on a phone could succeed while the page reported a sign-in failure. Another device could keep showing the old address, reject the correct password, or incorrectly say a confirmation email had been sent.

Impact
Production checks confirmed a completed email change despite the failure message, and a later request that sent no confirmation because the account already had the requested address. Reloading another device could still show outdated account details. The total number of affected users and the original start time were not established.
Recorded correction
Successive corrections were merged on September 27. The first callback correction did not handle confirmation in a separate browser, so a further change addressed that case. The reviewed record does not include a complete production email-delivery and cross-device recovery check after all corrections.
Cause, fix & verification: Email changes could show incorrect confirmations and account details

What caused it

Email confirmation depended on temporary proof held by the requesting browser, while account display and password checks could rely on an older address saved in the session. A request for the account's existing address could be accepted without sending an email, but the interface still announced one.

What we changed

  • Changed the email-change link and callback to support confirmation from another device, with distinct messages for a completed change, a remaining confirmation step, and an unusable link.
  • Check the account's current address before verifying a password or requesting an email change, and stop when the requested address is already in use by that account.
  • Refresh account details when restoring a saved session, while ignoring a delayed response after an account switch or sign-out.

Verification evidence

Browser regressions passed for confirmation in a fresh browser, expired links, correct-password checks after an address change, requests for the current address, and reloading after a change on another device. These checks used simulated authentication responses. Production email-template application and a complete delivered-email recovery check are separate from the application tests.

Prevention & follow-up

Retain cross-device and stale-session regression coverage. Record email-template verification and a complete delivered-email flow before upgrading this report to Resolved.

Link to this report
Fix recordedPay periods

Pay-period details could stay outdated or block menu actions

An expanded pay period could keep showing an older review list after its dates or reviews changed. Overlapping page elements could also prevent clicks on period actions.

Impact
The displayed total and expanded review list could disagree, including after widening a period's dates. Edit period and Add review could be obstructed by expanded details or neighboring rows; a later check found the progress bar overlapping the detail menu. These behaviors were reproduced in testing, but affected-user counts and an original incident window were not recorded.
Recorded correction
Refresh and menu corrections were merged on September 25, followed by a correction for the detail menu's overlap on September 26. The available evidence records automated browser verification rather than a complete historical production recovery check.
Cause, fix & verification: Pay-period details could stay outdated or block menu actions

What caused it

Expanded details did not consistently reload after relevant changes. Separately, menu layers could appear underneath nearby content or the progress bar and lose pointer access.

What we changed

  • Reload expanded details after account, review, and period changes, retain retry controls for failed reads, and prevent older responses from replacing newer results.
  • Keep open period menus above expanded rows, neighboring content, and the detail progress bar.

Verification evidence

Styled browser tests passed for date edits, refreshed lists, cache reuse, failed reads, and delayed responses. Menu checks exercised actual pointer access at mobile and desktop widths in light and dark themes, with a separate regression for the detail progress bar overlap.

Prevention & follow-up

Keep summary and expanded-list checks together when changing period membership, and retain pointer-access tests for menus across supported layouts.

Link to this report
Fix recordedSaving records

Delayed saves could clear a new draft and follow-up retries could create duplicates

A slow save could finish after another draft had been opened and clear that draft. Retrying a follow-up after a lost response could create a second copy.

Impact
The reliability audit reproduced loss of newly entered, unsaved draft text and duplicate follow-ups with synthetic records. The draft issue affected Review, Bank, and Follow-Up dialogs. The evidence does not establish that a customer encountered either failure or that previously saved reviews were deleted.
Recorded correction
Corrections were merged on September 16 after reproducing both failures. The release records successful regression checks, but a complete historical production recovery check was not recorded in the reviewed evidence.
Cause, fix & verification: Delayed saves could clear a new draft and follow-up retries could create duplicates

What caused it

Save completion was not consistently tied to the form session that initiated it. A retried follow-up creation could be treated as a new operation after the original response was lost.

What we changed

  • Keep pending forms from being closed or edited and bind completion to the form session that started the save.
  • Preserve the identity of a follow-up creation across an uncertain response so a retry returns the original result instead of creating another record.

Verification evidence

Browser tests passed for delayed saves and replacement drafts in the real dialogs. Follow-up regressions covered lost responses, preserved edited drafts, simultaneous retries, account ownership, and later updates or deletion. The tests used synthetic records and do not establish customer-impact counts.

Prevention & follow-up

Retain delayed-response and retry coverage when changing record creation or form lifecycle behavior.

Link to this report
Fix recordedAccount recovery

Valid account backups could be rejected during restore

Account restore could reject a supported backup because of an ordinary write limit, retired review statuses, or inconsistent file-size checks between export and restore.

Impact
Testing reproduced failures when restoring larger supported accounts, comparing older backup records, and processing files near the size limit. A downloaded backup could exceed what restore would accept. The audit used synthetic records; it did not establish affected customer counts or production backup corruption.
Recorded correction
Corrections were merged on September 16. Hosted release checks completed a full supported restore, but these were disposable test environments rather than a documented customer production recovery.
Cause, fix & verification: Valid account backups could be rejected during restore

What caused it

A full restore encountered a write limit intended for ordinary interactive changes. Comparisons still considered retired statuses, and export and restore did not consistently measure the bytes in the complete restore request.

What we changed

  • Allow the supported restore to complete as one bounded transaction while retaining ownership checks, account quotas, and normal write limits.
  • Ignore retired statuses when comparing backup records while preserving checks against overwriting changed content.
  • Use consistent byte-size checks for export, download, parsing, and the complete restore request.

Verification evidence

Fresh and upgraded disposable databases passed a 6,500-record restore, repeat restore, rollback, and permission checks. Backup regressions covered retired statuses, multibyte and escaped text, and files near the size limit. These results verify the reproduced failures without claiming a historical production recovery.

Prevention & follow-up

Retain full-size restore and export-to-restore checks for current and older backups when changing backup formats or write limits.

Link to this report
ResolvedPay periods

Older reviews were missing from pay-period totals

Older reviews without an explicit pay-period assignment were omitted from period totals and review lists, even though Reports included them by date.

Impact
The investigated period showed 18 reviews instead of 43. All 25 omitted reviews were still present in production. The investigation established an assignment and counting discrepancy, rather than deletion of those records; it did not establish how many other accounts had encountered the same display problem.
Recovery verified
The documented, owner-authorized production repair assigned the 25 existing reviews to their period and verified a total of 43. The account's overall review count stayed unchanged, and content checks confirmed that the repair preserved review content. The application correction was merged on September 16.
Cause, fix & verification: Older reviews were missing from pay-period totals

What caused it

Reviews created before explicit period assignments were introduced could remain unassigned. Later cloud summary and selective-loading paths omitted the date-based fallback that Reports still used, causing the views to disagree.

What we changed

  • Use the same period-membership rule for summaries, selective review loading, and the default Reviews view, with explicit assignments taking priority over date-based membership.
  • Load every page of matching records and refresh cached period reads when dates change.
  • Repair only the verified legacy assignments in the affected account, with checks on ownership, dates, the exact records, and preserved content.

Verification evidence

Production checks documented the corrected assignments, the period total, unchanged overall review count, and preserved content. Regression tests reproduced the missing-review case and checked date boundaries, assignment precedence, pagination, account isolation, and agreement with Reports. The production repair supports this entry's Resolved status; the regression tests are separate evidence for the application correction.

Prevention & follow-up

Keep cloud summaries, loaded review lists, and Reports covered by the same membership checks, including reviews created before explicit assignments existed.

Link to this report
Fix recordedAccount access

Different accounts in browser tabs could show the wrong account

When two accounts were signed in through separate tabs in the same browser, one tab could display the other account while still saving changes under its original account.

Impact
Testing reproduced a saved bank review under an account different from the one shown, followed by an error when the app tried to read it back. Profile edits could also target the original account. The issue required multiple signed-in accounts in the same browser. Affected customer counts, the original start date, and production exploitation have not been established.
Recorded correction
A correction was prepared on September 14 after reproducing the issue with synthetic accounts. This entry records that correction; it does not establish a historical production incident window.
Cause, fix & verification: Different accounts in browser tabs could show the wrong account

What caused it

Tabs shared sign-in notifications, but ordinary sign-in credentials belonged to individual tabs. The interface could accept another tab's account without changing the credentials used to save data.

What we changed

  • Keep the displayed account aligned with the credentials stored for that tab and ignore mismatched account updates from other tabs.
  • Keep existing tabs on their own account when another account replaces the remembered sign-in, while retaining shared sign-out and password recovery.

Verification evidence

Browser regression tests reproduced the original failure and passed after the correction for ordinary and remembered sign-in. They checked bank-review saves, profile edits, account display, and shared sign-out using synthetic accounts and simulated service responses. Session restoration and password-recovery tests also passed. These tests did not use customer accounts or establish production exploitation.

Prevention & follow-up

Retain multi-account browser regression coverage when changing sign-in, remembered sessions, or password recovery.

Link to this report
Fix recordedAccount access

Remembered sign-in still showed the welcome-back form

Returning visitors could see the sign-in form despite having selected “Keep me signed in on this device.”

Impact
The saved session was not automatically resumed from the landing page, making the remembered-sign-in option appear ineffective. The number of affected users and the original issue start time were not recorded.
Recorded correction
The correction was merged on September 8 at 03:40 UTC, and its production deployment was recorded as successful.
Cause, fix & verification: Remembered sign-in still showed the welcome-back form

What caused it

The landing page opened the requested sign-in form without first checking for a saved session.

What we changed

  • Check for a saved session before showing sign-in and send returning signed-in users to their workspace.
  • Refresh an expired saved session when possible, with manual sign-in available if restoration fails.

Verification evidence

Automated checks passed for restoring saved sessions, refreshing expired sessions, and signing out. A complete browser-close-and-reopen production test was not recorded.

Prevention & follow-up

Retain session-restoration regression coverage and verify a full browser restart when checking remembered sign-in.

Link to this report
Fix recordedAccount access

Password-reset links failed across browser tabs

A password-reset email opened in another tab could fail even when the reset was requested from the same browser.

Impact
The recovery flow could not complete in the new tab. The available record does not establish the number of affected users or the full incident window.
Recorded correction
The cross-tab correction was merged on September 5 at 04:15 UTC. Automated recovery checks passed; a completed production email-delivery test was not recorded in that release evidence.
Cause, fix & verification: Password-reset links failed across browser tabs

What caused it

The temporary proof needed to exchange a recovery code was stored only in the tab that requested the reset. A second tab could not access it.

What we changed

  • Allowed a reset requested in one tab to complete in another tab of the same browser, while preserving session isolation.
  • Replaced raw callback errors with instructions for restarting recovery when a link cannot be used.

Verification evidence

Automated tests verified recovery across tabs in the same browser, rejection in a separate browser, and session isolation. Release checks passed.

Prevention & follow-up

Keep cross-tab recovery and session isolation covered by regression tests. Branded email configuration and delivery verification are separate from this application fix.

Link to this report
ResolvedReports

Report selection and edits could leave outdated output

An audit reproduced reports that still copied the previously selected pay period, and link edits that left the platform and related report fields out of sync. Long review text also appeared clipped in Excel output.

Impact
Copied reports could disagree with the current period selection or edited review link. Spreadsheet clipping affected presentation: comparison with the source confirmed that the complete review text remained in the workbook and clipboard. The record does not establish how many customer reports were affected.
Recovery verified
The correction was merged on September 5 at 03:22 UTC, and the production deployment was subsequently verified as ready.
Cause, fix & verification: Report selection and edits could leave outdated output

What caused it

Changing the period selection did not invalidate an already generated report. Link edits did not refresh dependent metadata. A fixed spreadsheet row height hid wrapped text. Search also lacked a clear explanation that copying included the complete report.

What we changed

  • Cleared generated output when the selected pay period changes and synchronized metadata derived from edited links.
  • Preserved Canadian marketplace labels and made the complete-report copy scope explicit when search hides rows.
  • Removed the fixed spreadsheet body-row height and stopped wrapping URL cells in the export engine.

Verification evidence

Report regression and release checks passed. Comparisons with the source and the Windows clipboard confirmed that the reported long reviews retained their complete text. Preview checks and production deployment readiness were also verified.

Prevention & follow-up

Keep period switching and dependent-field edits in report regression coverage. This is a historical export-engine issue; the current interface does not offer an Excel download button. Spreadsheet software can still apply its own formatting after a paste.

Link to this report
Fix recordedOnboarding

Returning accounts could be offered first-run setup again

First-run setup depended on a completion flag in the current browser, so an existing account could be treated as new on another browser or after clearing browser data.

Impact
Returning users could receive an unnecessary setup prompt. The historical patch establishes the behavior and correction, but does not record affected-user counts or an incident start time.
Recorded correction
The correction was committed on September 1 at 00:59 UTC (August 31 in Eastern time). A separate historical production recovery timestamp was not recorded in the source reviewed.
Cause, fix & verification: Returning accounts could be offered first-run setup again

What caused it

A browser-local completion flag was used to decide whether to offer onboarding, rather than checking whether the signed-in account was newly created.

What we changed

  • Based the first-run decision on the account profile and waited for that check before offering setup.
  • Distinguished newly created profiles from existing profiles and shared the pending profile check to avoid duplicate first-run decisions.

Verification evidence

Separate tests cover new and returning accounts. The current profile and onboarding regression tests passed when this report was prepared.

Prevention & follow-up

Continue testing new and returning accounts separately. Clearing browser preferences should not be treated as evidence that the account itself is new.

Link to this report

July 20261 report

Fix recordedMobile navigation

Workspace navigation was clipped on mobile

The workspace's primary navigation extended beyond the viewport on narrow screens, clipping the available tabs.

Impact
Mobile users could have difficulty seeing or reaching navigation controls. This was a layout problem; the historical record does not quantify affected users or establish a service outage.
Recorded correction
The mobile layout fix was merged on July 22 at 02:07 UTC (July 21 in Eastern time). The original issue start time was not recorded.
Cause, fix & verification: Workspace navigation was clipped on mobile

What caused it

The four primary tabs at that time remained in a single row that was wider than the mobile viewport.

What we changed

  • Arranged the mobile tabs in a full-width, two-column grid.
  • Preserved the tablet and desktop navigation arrangement.

Verification evidence

The merged repair records passing lint, unit tests, and a production build. Its visual quality checks passed against approved desktop, tablet, and mobile baselines.

Prevention & follow-up

Keep checking navigation at narrow widths when tabs or labels change. The historical report describes the four-tab interface that existed at the time.

Link to this report

June 20261 report

Fix recordedReview conversion

Converted follow-ups remained in the pending list

Converting a follow-up into a review did not remove the original follow-up, leaving completed work in the pending list.

Impact
The same customer interaction could appear as both a saved review and an outstanding follow-up. The available record does not quantify affected accounts or establish duplicate saved reviews.
Recorded correction
The cleanup correction was committed on June 9 at 13:38 UTC. The original incident window and a separate production recovery timestamp were not preserved in the reviewed record.
Cause, fix & verification: Converted follow-ups remained in the pending list

What caused it

The conversion opened a prefilled review form without retaining the source follow-up identity for cleanup after the review was saved.

What we changed

  • Tracked the source follow-up through conversion and removed it only after the review was saved, for both local and cloud records.
  • Reported cleanup failures separately instead of implying that both steps had succeeded.
  • A later reliability update made cloud review creation and follow-up removal complete together, with safe retries.

Verification evidence

The June fix records follow-up removal after saving and clear feedback if removal fails. Later authenticated tests passed for completing both changes together and retrying safely. The local browser conversion test also passed when this report was prepared.

Prevention & follow-up

Keep testing that conversion saves the review, removes the follow-up, and handles retries safely. The later reliability improvement is separate from the original June fix.

Link to this report

Something missing or still not working?

Email support@repstack.reviews with what happened and when. Reports are based on recorded checks and repair evidence; we update them when new facts are confirmed. Customer information and private operational details are excluded.