Skip to content

Fix 359 storage errors - #407

Merged
Bohreromir merged 3 commits into
fix-359-error-handlingfrom
fix-359-storage-errors
Oct 29, 2026
Merged

Bohreromir merged 3 commits into
fix-359-error-handlingfrom
fix-359-storage-errors

Conversation

@Bohreromir

@Bohreromir Bohreromir commented Oct 26, 2026 •

Copy link
Copy Markdown
Member

Description

Storage endpoints used 401 both for an expired session and for a request without a usable storage connection. The client mapped every 401 to "not connected", so an expired session showed connection errors, and every missing connection made the client re-check the session.

closes #359

Docs

Release note

Checklist

Author

  • AI review done, findings addressed
  • Tests added or updated
  • Changelog updated (if the repo keeps one)

Reviewer

  • Useful comments and logging
  • Docs added or updated per the style guide

Acceptance

  • Check for release notes and docs

Storage endpoints used 401 both for an expired session and for a request
without a usable storage connection. The client mapped every 401 to
"not connected", so an expired session showed connection errors, and
every missing connection made the client re-check the session.

Answer a missing or unknown connection with 409 and
reason: 'not-connected' instead, so 401 only means the session expired.
The storage client, upload and page loads recognise the reason; a 409
without it is still an edit conflict.
The details modals, the directory size calculation, archive toasts and
the save fallback toast showed err.message as is: the server's English
text, raw upstream errors, or "Request failed with status 502".

Map the error code to translated messages instead. Details requests
get specific messages for a missing connection, denied access and
missing items, and a "failed to load" fallback for everything else.
The unused storage_details_error_fetch_* keys serve as these fallbacks
and no longer take a status.
@github-actions

github-actions Bot commented Oct 26, 2026 •

Copy link
Copy Markdown

Coverage Report

Status Category Percentage Covered / Total
🔵 Lines 66.53% 8980 / 13497
🔵 Statements 65.33% 12101 / 18521
🔵 Functions 67.07% 2903 / 4328
🔵 Branches 56.83% 5192 / 9136
File Coverage
File Stmts Branches Functions Lines Uncovered Lines
Changed Files
src/hooks.server.ts 0% 0% 0% 0% 18-142
src/lib/components/storage/modals/DetailsModal.svelte 0% 0% 0% 0% 25-146
src/lib/components/storage/modals/PreviewModal.svelte 70.71% 61.21% 74.77% 67.08% 153, 163, 165, 169, 181, 215-220, 257-259, 303, 334-357, 363, 439, 460-552, 556, 560-562, 570, 586-587, 606-622, 630-647, 653-654, 660, 681-716, 731-759, 787-789, 813-817, 812, 827, 826, 786, 857, 899, 898, 895, 1002-1003, 1010-1011, 997, 1085-1082
src/lib/components/storage/modals/details/BucketDetails.svelte 0.29% 0% 0% 0.64% 60-66
src/lib/components/storage/modals/details/DirectoryDetails.svelte 0% 0% 0% 0% 24-288
src/lib/server/storage/connection.ts 96.15% 93.75% 50% 95.83% 82
src/lib/server/storage/not-connected.ts 100% 100% 100% 100%
src/lib/server/storage/request-context.ts 86.95% 80% 83.33% 94.44% 27, 34, 51
src/lib/storage/archive.svelte.ts 95.61% 90.62% 88.46% 96.39% 118, 132, 171, 245-246
src/lib/storage/errors.ts 100% 100% 100% 100%
src/lib/storage/storage-fetch.ts 96.29% 95.45% 100% 100% 29
src/lib/storage/upload.ts 2.7% 0% 11.11% 2.94% 33-108
src/routes/(app)/api/storage/archive/extract/+server.ts 0% 0% 0% 0% 32-123
src/routes/(app)/api/storage/archive/listing/+server.ts 0% 0% 0% 0% 24-65
src/routes/(app)/api/storage/buckets/+server.ts 93.75% 83.33% 100% 93.75% 37
src/routes/(app)/storage/+layout.ts 0% 0% 0% 0% 13-105
src/routes/(app)/storage/browse/[connection]/[bucket]/[...prefix]/+page.ts 0% 0% 0% 0% 10-85
Generated in workflow #1182 for commit ddd2d00 by the Vitest Coverage Report Action

@Bohreromir
Bohreromir changed the base branch from main to fix-359-error-handling October 26, 2026 13:10
@Bohreromir
Bohreromir added this pull request to stack #408 October 26, 2026 13:11
@Bohreromir Bohreromir moved this to Development: Waiting for Review in Stackable Engineering Oct 26, 2026
@Bohreromir
Bohreromir marked this pull request as ready for review October 26, 2026 13:15

@lfrancke lfrancke left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It took me a while (from the title only) to understand what those 359 errors are supposed to be :)

@Bohreromir
Bohreromir added this pull request to the merge queue Oct 29, 2026
Merged via the queue into main with commit 5c3a97a Oct 29, 2026
12 checks passed
@Bohreromir
Bohreromir deleted the fix-359-storage-errors branch October 29, 2026 08:36
@Bohreromir Bohreromir moved this from Development: Waiting for Review to Development: Done in Stackable Engineering Oct 29, 2026
@lfrancke lfrancke moved this from Development: Done to Done in Stackable Engineering Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

Graceful error handling across the app

2 participants