In yoyaku's end-to-end functional tests, two scenarios that submit the bound webform to advance a workflow's form step are skipped: under the subdirectory install the CI test runner uses, the Orchestra interaction-webform token resume does not bind the submission to its process instance, so the form step never advances.

The same flow works under a root install, so this looks specific to base-path handling in the interaction-webform continuation (the token resume link, or the submission-to-instance binding). Filing so the yoyaku end-to-end skips can reference a real issue.

To reproduce: run yoyaku's BookingWorkflowE2eTest::testWebformSubmissionAdvancesFormStep with the skip removed under a subdirectory base URL.

Issue fork orchestra-3611593

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mably created an issue. See original summary.

mably’s picture

mably commented

Follow-up after digging in: it reproduces, but it looks like a test-harness issue on the yoyaku side rather than an orchestra bug, so this can most likely be closed.

The trigger is the base path. The drupal.org GitLab CI serves the site under a subdirectory: the gitlab_templates pipeline sets SIMPLETEST_BASE_URL: http://localhost/$_WEB_ROOT with _WEB_ROOT: web, so functional tests run at http://localhost/web. At the site root it passes, which is why it did not reproduce.

The failing yoyaku test reached the bound step by hand-building the webform URL and appending the capability token (drupalGet('/webform/yoyaku_booking', ['query' => ['orchestra_interaction' => ...]])). Orchestra's own WebformTaskReviewTest and BackLoopResumeTest instead enter through the dispatcher step URL (orchestra_interaction.urls::stepUrl()), navigated with a small helper that splits the base-path-qualified URL back into path plus query so drupalGet does not double the base path; they pass under the same base path in orchestra's CI.

Switching the yoyaku tests to the dispatcher entry fixes them (green locally). I will confirm on yoyaku CI under the base path, then close this as not-an-orchestra-bug unless CI shows otherwise. Thanks for looking.

mably’s picture

mably commented

Correction to my previous comment: switching the yoyaku tests to the dispatcher entry did not fix it under the base path, so this is not merely a test-entry issue. With both end-to-end tests un-skipped, CI (serving at http://localhost/web) still fails them: after submitting the bound webform the visitor lands on the webform's own confirmation page rather than returning to the interaction dispatcher, and the workflow step does not advance (it stays on the form node).

The shipped yoyaku_booking webform uses confirmation_type: page with the handler's return_to_workflow enabled; that combination returns to the workflow at the site root but not under /web. Orchestra's own webform tests pass under /web, so the trigger is specific to this configuration, not yet pinned. I have restored the skips (still tracked here) rather than ship failing tests, and will keep this open for a proper root-cause. Apologies for the premature earlier read.

mably’s picture

mably commented
Status: Active » Closed (works as designed)

Closing as works-as-designed for orchestra: this turned out to be a yoyaku test bug, not an interaction-webform resume issue. The end-to-end tests submitted only name and email, but the shipped booking webform also requires a date-of-birth field, so the submission never validated and the workflow step never advanced (at the site root as much as under a base path). Filling the required fields, and entering through the interaction dispatcher as orchestra's own webform tests do, makes both end-to-end tests pass, including under the CI base path, which confirms the resume works correctly. Apologies for the two earlier misreads (test-entry, then base-path). The incidental easy_email PHP 8.4 deprecation hit along the way is reported at easy_email #3611615.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.