Skip to content

Add test case for timeout in API endpoint infrastructure#71

Merged
brandur merged 1 commit intomasterfrom
brandur-timeout-test
Jun 28, 2024
Merged

Add test case for timeout in API endpoint infrastructure#71
brandur merged 1 commit intomasterfrom
brandur-timeout-test

Conversation

@brandur
Copy link
Collaborator

@brandur brandur commented Jun 28, 2024

Follows up #63 with one more test case that checks to make sure the
right thing happens if a timeout occurs. (The API endpoint executor adds
a five seconds timeout to every run by default.)

Follows up #63 with one more test case that checks to make sure the
right thing happens if a timeout occurs. (The API endpoint executor adds
a five seconds timeout to every run by default.)
@brandur brandur requested a review from bgentry June 28, 2024 03:07
@brandur brandur merged commit c5f6188 into master Jun 28, 2024
@brandur brandur deleted the brandur-timeout-test branch June 28, 2024 04:22
brandur added a commit that referenced this pull request Jun 28, 2024
A partial fix for #73. Instead of always returning an internal error on
problems like insufficient privileges, instead return a user-facing API
error with a description of what's wrong.

This is only a partial fix because it requires the new API
infrastructure from #71 to work properly, so we'll need to convert the
rest of the endpoints over for it to be fully effective.
brandur added a commit that referenced this pull request Jun 28, 2024
A partial fix for #73. Instead of always returning an internal error on
problems like insufficient privileges, instead return a user-facing API
error with a description of what's wrong.

This is only a partial fix because it requires the new API
infrastructure from #71 to work properly, so we'll need to convert the
rest of the endpoints over for it to be fully effective.

One possibility is that we might want to just take any kind of
`*pgconn.PgError` and change that to a user-facing error. I didn't do
that here, but it strikes me as fairly plausible. I figure we should
maybe wait for one more type of error that's commonly encountered before
taking this step.
brandur added a commit that referenced this pull request Jun 28, 2024
A partial fix for #73. Instead of always returning an internal error on
problems like insufficient privileges, instead return a user-facing API
error with a description of what's wrong.

This is only a partial fix because it requires the new API
infrastructure from #71 to work properly, so we'll need to convert the
rest of the endpoints over for it to be fully effective.

One possibility is that we might want to just take any kind of
`*pgconn.PgError` and change that to a user-facing error. I didn't do
that here, but it strikes me as fairly plausible. I figure we should
maybe wait for one more type of error that's commonly encountered before
taking this step.
brandur added a commit that referenced this pull request Jun 28, 2024
A partial fix for #73. Instead of always returning an internal error on
problems like insufficient privileges, instead return a user-facing API
error with a description of what's wrong.

This is only a partial fix because it requires the new API
infrastructure from #71 to work properly, so we'll need to convert the
rest of the endpoints over for it to be fully effective.

One possibility is that we might want to just take any kind of
`*pgconn.PgError` and change that to a user-facing error. I didn't do
that here, but it strikes me as fairly plausible. I figure we should
maybe wait for one more type of error that's commonly encountered before
taking this step.
brandur added a commit that referenced this pull request Jun 29, 2024
A partial fix for #73. Instead of always returning an internal error on
problems like insufficient privileges, instead return a user-facing API
error with a description of what's wrong.

This is only a partial fix because it requires the new API
infrastructure from #71 to work properly, so we'll need to convert the
rest of the endpoints over for it to be fully effective.

One possibility is that we might want to just take any kind of
`*pgconn.PgError` and change that to a user-facing error. I didn't do
that here, but it strikes me as fairly plausible. I figure we should
maybe wait for one more type of error that's commonly encountered before
taking this step.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants