Skip to content

feat: timeout error-target fetch and fall back to error-path#648

Open
kaddynator wants to merge 4 commits into
jupyterhub:mainfrom
kaddynator:ft/error-target-error-path-fallback
Open

feat: timeout error-target fetch and fall back to error-path#648
kaddynator wants to merge 4 commits into
jupyterhub:mainfrom
kaddynator:ft/error-target-error-path-fallback

Conversation

@kaddynator

Copy link
Copy Markdown

Problem:

Today you must choose either --error-target or --error-path. If --error-target is set and the request to the custom error server fails (hub down, connection refused, etc.), CHP only returns the generic plain-text response. Static HTML under --error-path is never used in that case.

Change:

Permit both --error-target and --error-path. When --error-target is configured, CHP still tries the custom error URL first. On request error, serve HTML from --error-path using the existing rules ({code}.html, then error.html, else default).

Fix --error-path CLI help: it is a directory of HTML files, not another proto://host server.

Add a test that uses an unreachable errorTarget and asserts responses come from the error-path fixtures.

Backward compatibility:

Using only --error-target or only --error-path behaves as before. If both are set, behavior is: dynamic page when reachable; otherwise file-based fallback.

Comment thread lib/configproxy.js Outdated
if (eto === undefined || eto === null) {
eto = 10000;
}
this.errorTargetTimeout = typeof eto === "string" ? parseInt(eto, 10) : Number(eto);

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.

at this point, timeout should be an int, no need to handle the string here

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Addressed in 2fc0b9a. Thanks for the review!

Comment thread lib/configproxy.js Outdated
eto = 10000;
}
this.errorTargetTimeout = typeof eto === "string" ? parseInt(eto, 10) : Number(eto);
if (!Number.isFinite(this.errorTargetTimeout) || this.errorTargetTimeout < 1) {

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.

Let's remove this check. Rather than ignoring invalid values, we should assign what is given. If the value is invalid and leads to an error, an error is the right result.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Addressed in 2fc0b9a. Thanks for the review!

…or-path-fallback

# Conflicts:
#	package-lock.json
…ty fallback

Per review: CLI already coerces --error-target-timeout to an int via
commander's parseInt, so no need to re-parse here. Invalid values should
error naturally rather than being silently defaulted to 10000.
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.

3 participants