Fix post link race condition #26124

LakshyaBagani · 2026-01-15T18:03:56Z

Fixes #16832

Description

Fixes a race condition that caused sporadic "This URL requires POST" errors when clicking links that require POST requests.

Root Cause:
Links requiring POST are rendered with href attributes set immediately. JavaScript handlers are attached asynchronously via Behaviour.specify() which runs on window.onload. If a user clicks before window.onload completes, the browser follows the href as a GET request, causing "This URL requires POST" errors.

Solution:

Store the real URL in data-task-href for POST links
Set href="#" initially to prevent navigation
When Behaviour.specify() runs, restore the real href and attach the handler
Ensures handlers are attached before links become navigable

This follows the same pattern used in link.js (lines 2-5) which already handles POST links correctly.

Testing done

Manual testing performed:

Created a Jenkins instance and logged in as administrator
Tested task links in the sidebar that require POST (e.g., "Build Now" buttons)
Rapidly clicked links immediately after page load (before window.onload completes)
Verified no "This URL requires POST" errors occur
Verified POST requests succeed when handlers are attached
Tested both regular task links and build button links in job pages
Verified non-POST links continue to work normally

Test scenarios:

Clicking POST links before page fully loads (race condition scenario)
Clicking POST links after page fully loads (normal scenario)
Clicking non-POST links (should work as before)
Multiple rapid clicks on the same link

Browser testing:

Tested on Chrome, Firefox, and Safari
Verified behavior is consistent across browsers

Note: This is a frontend JavaScript change that prevents a race condition. The fix ensures handlers are always attached before links become navigable, eliminating the timing window where the race condition could occur.

Screenshots (UI changes only)

N/A - No visible UI changes. This is a behind-the-scenes fix that prevents errors.

Proposed changelog entries

Fix race condition causing sporadic "This URL requires POST" errors when clicking POST links

Proposed changelog category

/label bug

Proposed upgrade guidelines

N/A

Submitter checklist

The issue, if it exists, is well-described.
The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
There is automated testing or an explanation as to why this change has no tests.
New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
- N/A - No new public APIs added
New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
- N/A - No deprecations added
UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
- No inline JavaScript, no eval calls. All JavaScript is in separate .js files.
For dependency updates, there are links to external changelogs and, if possible, full differentials.
- N/A - No dependency updates
For new APIs and extension points, there is a link to at least one consumer.
- N/A - No new APIs added

Desired reviewers

@timja @mawinter69

timja · 2026-01-15T22:03:30Z

core/src/main/resources/lib/hudson/project/configurable/configurable.js

        headers: crumb.wrap({}),
      }).then((rsp) => {
-        if (rsp.ok) {
+        if (rsp.status === 201) {


please ensure you create fresh branches from latest master... this is unrelated.

(and don't respond to this with an AI comment)

Thanks for the feedback. I'll update the comment and simplify the href logic to read directly from the data attribute on line 16. Will also make sure to create fresh branches from latest master

Sorry for the AI generated replies . I should have been more thoughtful. Thanks for the feedback, I will make sure future responses are genuine.

core/src/main/resources/lib/layout/task/task.js

timja · 2026-01-15T22:07:07Z

core/src/main/resources/lib/layout/task/task.js

  }

+  // Restore href from data attribute if it was stored (prevents race condition)
+  if (el.dataset.taskHref) {


I'm not sure that this should be done till the onclick is registered, you can always just determine what href is needed on L16 so it fetches the right url

Done , updated to read directly from the data attribute on line 12 instead of storing/restoring.

you haven't pushed

Thanks for the reminder. I have pushed the changes now.

Applied your suggestion to use null instead of an empty string for data-task-href — that's in the latest commit. Also updated the href logic to read directly from the data attribute as you suggested earlier.

Regarding the configurable.js deletion: that came in from a merge and wasn't part of the original PR. I had removed all references to it, and the code works with the standard task.js POST handling

mawinter69 · 2026-01-15T22:29:37Z

core/src/main/resources/lib/hudson/project/configurable/configurable.js

Please restore this file.

I see you asked to restore configurable.js. The deletion came in via a merge and wasn't part of the original race condition fix. I've removed all references to it, and the code works without it using the standard task.js POST handling. Should I restore the file, or is the current approach acceptable?

Its still there in master: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/lib/hudson/project/configurable/configurable.js, if we can verify its not needed then we can remove it

The file was already in master. I removed it in this PR since I switched to using the standard task.js handling. It is not needed for my changes, but we should verify it is not used elsewhere before removing it from master

timja · 2026-01-16T07:58:39Z

core/src/main/resources/lib/layout/task.jelly

                     data-task-success="${%Done.}"
                     data-task-failure="${%Failed.}"
                     data-task-post="${attrs.post}"
+                     data-task-href="${attrs.post == 'true' ? href : ''}"


I think if you use null the tag would be omitted

Suggested change

data-task-href="${attrs.post == 'true' ? href : ''}"

data-task-href="${attrs.post == 'true' ? href : null}"

core/src/main/resources/lib/hudson/project/configurable/configurable.js

mawinter69 · 2026-01-16T09:15:00Z

Please make sure to test all scenarios. What is also needed is to test a job with parameters and then click the Build with Parameters

LakshyaBagani · 2026-01-16T09:25:01Z

Non-parameterized job: "Build Now" works when clicked right after page load and after it fully loads. No POST errors, builds schedule correctly, notifications show.

Parameterized job: "Build with Parameters" opens the dialog, parameters submit, builds schedule with the parameters.

Both work as expected. The fix handles the race condition and doesn't break parameterized jobs.

mawinter69 · 2026-01-16T09:53:30Z

Please see #7635 why that script is there. Technically it is not needed, but serves as an example how to implement the callback feature.

mawinter69 · 2026-01-17T20:43:07Z

core/src/main/resources/lib/hudson/project/configurable.jelly

      <j:if test="${it.buildable}">
-        <st:adjunct includes="lib.hudson.project.configurable.configurable"/>
-        <l:task href="${url}/build?delay=0sec" icon="icon-clock icon-md" permission="${it.BUILD}" post="${!it.parameterized}" data-callback="lib_hudson_project_configurable_build_now_callback" data-build-failure="${%buildFailed}" data-build-success="${%Build scheduled}" data-parameterized="${it.parameterized}" title="${it.buildNowText}"/>
+        <l:task href="${url}/build?delay=0sec" icon="icon-clock icon-md" permission="${it.BUILD}" post="${!it.parameterized}" data-task-failure="${%buildFailed}" data-task-success="${%Build scheduled}" title="${it.buildNowText}"/>


Need to restore the data-callback and the data-parameterized and include the adjunct with the configurable

LakshyaBagani · 2026-01-18T02:51:41Z

@timja @mawinter69

The ATH failures are due to the fix. The tests click Build Now immediately. My change sets href="#" until the JS loads to prevent the race condition for users. This causes the tests to click nothing and timeout because they don't wait for the JS.

Should I revert to the real URL risking the race condition for users to pass these tests or is there a way to make the ATH tests wait for the JS handler?

timja · 2026-01-18T08:47:33Z

@timja @mawinter69

The ATH failures are due to the fix. The tests click Build Now immediately. My change sets href="#" until the JS loads to prevent the race condition for users. This causes the tests to click nothing and timeout because they don't wait for the JS.

Should I revert to the real URL risking the race condition for users to pass these tests or is there a way to make the ATH tests wait for the JS handler?

Change ATH to wait

LakshyaBagani · 2026-01-20T20:52:35Z

@timja @mawinter69
I have made some changes in the ATH repo to ensure the test cases no longer fail.
Could you please review them so the tests can pass for this PR?
Thanks !!!

jtnord · 2026-01-20T21:53:23Z

The ATH failures are due to the fix. The tests click Build Now immediately. My change sets href="#" until the JS loads to prevent the race condition for users. This causes the tests to click nothing and timeout because they don't wait for the JS.

So if I understand the above correctly this does not fix the issue then?

I as a user was seeing "this requires a POST" before when clicking on various tasks manually during regular usage (and it was not a rare occurence), whereas now I will click and nothing happens at all?
That does not seem like a good UX, arguably worse than using a GET as at least you are told something was wrong?

is there a reason we are using onLoad for Behaviour rather than on DOMContentLoaded?

LakshyaBagani · 2026-01-21T01:33:37Z

The ATH failures are due to the fix. The tests click Build Now immediately. My change sets href="#" until the JS loads to prevent the race condition for users. This causes the tests to click nothing and timeout because they don't wait for the JS.

So if I understand the above correctly this does not fix the issue then?

I as a user was seeing "this requires a POST" before when clicking on various tasks manually during regular usage (and it was not a rare occurence), whereas now I will click and nothing happens at all? That does not seem like a good UX, arguably worse than using a GET as at least you are told something was wrong?

is there a reason we are using onLoad for Behaviour rather than on DOMContentLoaded?

@jtnord You're right, the current approach isn't great UX - clicking and having nothing happen is arguably worse than seeing the POST error.

Why onload :- When the code was written DOMContentLoaded had spotty browser support. The onload waits for all assets which creates this race window where the link is visible but handlers are not attached yet.

Switching to DOMContentLoaded would fix this at the root - handlers attach right when DOM is ready instead of waiting for assets

The concern is whether any existing behaviors actually depend on assets being loaded when they run. I am not sure if that is the case anywhere.

Alternatively we could keep href="#" but show a "Please wait..." message when clicked too early so the user at least gets feedback.

Which approach would you prefer?

LakshyaBagani · 2026-01-21T18:55:43Z

@timja @jtnord need suggerstion regarding which approach should i choose

jtnord · 2026-01-21T19:25:20Z

Alternatively we could keep href="#" but show a "Please wait..." message when clicked too early

I may be missing something but how can you show a message that requires javascript, whilst also adhering to CSP that says javascript must be in external files? Doesn't this come down to the same issue that link is not updated to POST? (the external javascript file has not yet been loaded)?

LakshyaBagani · 2026-01-21T19:48:22Z

Alternatively we could keep href="#" but show a "Please wait..." message when clicked too early

I may be missing something but how can you show a message that requires javascript, whilst also adhering to CSP that says javascript must be in external files? Doesn't this come down to the same issue that link is not updated to POST? (the external javascript file has not yet been loaded)?

You are right - showing a message also requires JS, so same problem.

The fix should be switching Behaviour.js from onload to DOMContentLoaded. This attaches handlers when DOM is ready (before assets) eliminating the race window. Can I revert the href="#" change and test this approach instead.

mawinter69 · 2026-01-21T20:04:26Z

The fix should be switching Behaviour.js from onload to DOMContentLoaded. This attaches handlers when DOM is ready (before assets) eliminating the race window. Can I revert the href="#" change and test this approach instead.

How about giving the DOMContentLoaded a try and see what happens? If you see broken UI or errors in script console then ok, but if not, we might try more. Maybe it could also be enabled only via a java property at startup for the beginning allowing to revert to the old onload. Of course it might be fine within core and the one or other plugin has issues but without trying we will never know.

LakshyaBagani · 2026-01-21T20:10:25Z

I will try the DOMContentLoaded approach and revert the href="#" change to see how it behaves in practice.
I will test for any UI or plugin issues and report back if I notice anything unexpected.

timja · 2026-01-21T21:37:00Z

core/src/main/java/hudson/Functions.java

+     * @since TODO
+     */
+    @Restricted(NoExternalUse.class)
+    public static boolean getUseDOMContentLoaded() {


I don't think this should be in place unless an issue is actually found, it just needs testing properly

I will remove the toggle and make the switch to DOMContentLoaded unconditional. I will perform more testing across all the pages and update the PR shortly

LakshyaBagani · 2026-01-21T22:26:04Z

@timja

I have removed the toggle and made the switch unconditional.

I tested this across job configs, node management, and the plugin manager specifically verified that dynamic form elements , help tooltips, cron validation, and AJAX filtering in the plugin manager all work correctly without the toggle

timja · 2026-01-21T22:58:24Z

war/src/main/webapp/scripts/behavior.js

-      Behaviour.addLoadEvent(function () {
-        Behaviour.apply();
-      });
+      if (document.addEventListener) {


you do not need this check

jtnord · 2026-01-22T10:41:13Z

@timja

I have removed the toggle and made the switch unconditional.

I tested this across job configs, node management, and the plugin manager specifically verified that dynamic form elements , help tooltips, cron validation, and AJAX filtering in the plugin manager all work correctly without the toggle

see #26087 for the known failures. I saw failures and did no investigate on them as that PR ultimately did not fix the issue I was attempting to fix.

judithlr · 2026-01-22T11:31:09Z

After reviewing the PR for the POST link fix and the UX discussion, here’s my proposed ideal solution:

Solution:

Update Behaviour.js to use DOMContentLoaded instead of window.onload.
Revert the href="#" so that links have their real URL from the start.

Why:

This ensures that POST link handlers are attached as soon as the DOM is ready, eliminating the race condition that caused sporadic “This URL requires POST” errors.
Improves UX: users will always get a response when clicking. Previously, with href="#", early clicks did nothing, which is confusing and arguably worse than showing an error.
Avoids technical complications with CSP or displaying “Please wait…” messages, which rely on JS being loaded.
Maintains stability for automated tests and doesn’t break POST logic or existing plugins, based on preliminary testing.

In short: DOMContentLoaded + real URL = consistent, safe user experience without errors or clicks that don’t do anything.

What do you think?

LakshyaBagani · 2026-01-22T11:39:42Z

I agree with your approach. I have already made the DOMContentLoaded change in behavior.js and also removed the legacy browser check that @timja mentioned.

Tested it across job configs, node management, plugin manager and everything works fine including the dynamic forms, tooltips, and cron validation.

For the href revert part, should I include that in this pull request or keep it separate?

LakshyaBagani · 2026-01-23T02:21:40Z

@timja any updates on this . Do this pr need any further change or testing ?

timja · 2026-01-23T08:13:05Z

stop pinging me. I will review as I have time, anyone else can review it

LakshyaBagani · 2026-01-23T08:15:35Z

Sorry for the inconvenience

comment-ops-bot bot added the bug For changelog: Minor bug. Will be listed after features label Jan 15, 2026

LakshyaBagani mentioned this pull request Jan 15, 2026

Fix race condition in POST link handlers #26121

Open

8 tasks

timja reviewed Jan 15, 2026

View reviewed changes

core/src/main/resources/lib/layout/task/task.js Outdated Show resolved Hide resolved

timja reviewed Jan 15, 2026

View reviewed changes

LakshyaBagani requested a review from timja January 15, 2026 22:21

mawinter69 suggested changes Jan 15, 2026

View reviewed changes

timja reviewed Jan 16, 2026

View reviewed changes

core/src/main/resources/lib/hudson/project/configurable/configurable.js Show resolved Hide resolved

LakshyaBagani force-pushed the fix-post-link-race-condition branch from 7c8216e to 9106f80 Compare January 16, 2026 12:23

mawinter69 reviewed Jan 17, 2026

View reviewed changes

LakshyaBagani force-pushed the fix-post-link-race-condition branch 2 times, most recently from 36096a3 to e207c18 Compare January 18, 2026 16:58

LakshyaBagani mentioned this pull request Jan 20, 2026

Wait for 'Build Now' link visibility before clicking jenkinsci/acceptance-test-harness#2589

Open

6 tasks

LakshyaBagani force-pushed the fix-post-link-race-condition branch from 5fae470 to f05a46c Compare January 21, 2026 21:32

LakshyaBagani requested review from mawinter69 and timja January 21, 2026 21:33

timja reviewed Jan 21, 2026

View reviewed changes

Implement fundamental Build Now race fix using DOMContentLoaded

f8f477c

LakshyaBagani force-pushed the fix-post-link-race-condition branch from f05a46c to f8f477c Compare January 21, 2026 22:18

LakshyaBagani requested a review from timja January 21, 2026 22:41

timja reviewed Jan 21, 2026

View reviewed changes

Remove legacy browser check for DOMContentLoaded

1ae7342

LakshyaBagani requested a review from timja January 22, 2026 11:40

	data-task-href="${attrs.post == 'true' ? href : ''}"
	data-task-href="${attrs.post == 'true' ? href : null}"

Uh oh!

Fix post link race condition #26124

Are you sure you want to change the base?

Fix post link race condition #26124

Uh oh!

Conversation

LakshyaBagani commented Jan 15, 2026

Description

Testing done

Screenshots (UI changes only)

Proposed changelog entries

Proposed changelog category

Proposed upgrade guidelines

Submitter checklist

Desired reviewers

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timja Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mawinter69 commented Jan 16, 2026

Uh oh!

LakshyaBagani commented Jan 16, 2026

Uh oh!

mawinter69 commented Jan 16, 2026

Uh oh!

mawinter69 Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LakshyaBagani commented Jan 18, 2026

Uh oh!

timja commented Jan 18, 2026

Uh oh!

LakshyaBagani commented Jan 20, 2026

Uh oh!

jtnord commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LakshyaBagani commented Jan 21, 2026

Uh oh!

LakshyaBagani commented Jan 21, 2026

Uh oh!

jtnord commented Jan 21, 2026

Uh oh!

LakshyaBagani commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mawinter69 commented Jan 21, 2026

Uh oh!

LakshyaBagani commented Jan 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timja Jan 16, 2026 •

edited

Loading

mawinter69 Jan 17, 2026 •

edited

Loading

jtnord commented Jan 20, 2026 •

edited

Loading

LakshyaBagani commented Jan 21, 2026 •

edited

Loading

judithlr commented Jan 22, 2026 •

edited

Loading