Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We should delineate internal API errors, wrangler errors, and user errors #515

Closed
caass opened this issue Feb 22, 2022 · 2 comments
Closed
Labels
maintenance Maintenance task

Comments

@caass
Copy link
Contributor

caass commented Feb 22, 2022

There should be a clear difference in how we handle internal API errors, errors that occur within wrangler, and errors that result from the user (e.g. an esbuild failure due to a problem with the worker code).

@caass caass self-assigned this Feb 22, 2022
@caass caass added the enhancement New feature or request label Feb 22, 2022
@Electroid
Copy link
Contributor

It would be nice to also delineate between expected API errors and unexpected API errors.

@Electroid Electroid added this to the 2.1 milestone Feb 22, 2022
@Electroid Electroid moved this to Should-have in workers-sdk Feb 22, 2022
@caass caass removed their assignment Mar 16, 2022
@petebacondarwin petebacondarwin modified the milestones: Selected for development, Backlog May 15, 2022
@petebacondarwin petebacondarwin moved this to Backlog in workers-sdk May 15, 2022
@petebacondarwin petebacondarwin removed this from the Backlog milestone May 15, 2022
@petebacondarwin petebacondarwin added the maintenance Maintenance task label May 30, 2022
@penalosa penalosa removed the enhancement New feature or request label Jun 15, 2023
mrbbot added a commit that referenced this issue Oct 31, 2023
Similar to #475, we weren't deleting the `MF-Original-URL` header
from incoming requests, leading to incorrect URLs in the loopback
server when the incoming request was passed-through as the cache key.

Tests also needed to be updated as the storage location is now based
off the actual URL passed to `dispatchFetch()`.
mrbbot added a commit that referenced this issue Nov 1, 2023
Similar to #475, we weren't deleting the `MF-Original-URL` header
from incoming requests, leading to incorrect URLs in the loopback
server when the incoming request was passed-through as the cache key.

Tests also needed to be updated as the storage location is now based
off the actual URL passed to `dispatchFetch()`.
mrbbot added a commit that referenced this issue Nov 1, 2023
Similar to #475, we weren't deleting the `MF-Original-URL` header
from incoming requests, leading to incorrect URLs in the loopback
server when the incoming request was passed-through as the cache key.

Tests also needed to be updated as the storage location is now based
off the actual URL passed to `dispatchFetch()`.
mrbbot added a commit that referenced this issue Nov 1, 2023
Similar to #475, we weren't deleting the `MF-Original-URL` header
from incoming requests, leading to incorrect URLs in the loopback
server when the incoming request was passed-through as the cache key.

Tests also needed to be updated as the storage location is now based
off the actual URL passed to `dispatchFetch()`.
@penalosa
Copy link
Contributor

penalosa commented Feb 7, 2024

Addressed in #4707, with a distinction between UserErrors and other Errors

@penalosa penalosa closed this as completed Feb 7, 2024
@github-project-automation github-project-automation bot moved this from Backlog to Done in workers-sdk Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Maintenance task
Projects
None yet
Development

No branches or pull requests

4 participants