What causes "424 Failed Dependency (WebDAV, RFC4918)" in eclipse-vertx/vert.x?

Identify and fix the failed prerequisite request first, then retry the dependent operation.

424 Failed Dependency (WebDAV, RFC4918)

Error message

424 Failed Dependency (WebDAV, RFC4918)

What it means

SC_FAILED_DEPENDENCY is an HttpResponseExpectation constant for HTTP 424 (WebDAV, RFC4918). It indicates the request failed because a dependent request/operation it relied on failed. Vert.x exposes it for status assertions in HttpClient expectations.

Source

Thrown at vertx-core/src/main/java/io/vertx/core/http/HttpResponseExpectation.java:255

  /**
   * 421 Misdirected Request
   */
  HttpResponseExpectation SC_MISDIRECTED_REQUEST = status(421);

  /**
   * 422 Unprocessable Entity (WebDAV, RFC4918)
   */
  HttpResponseExpectation SC_UNPROCESSABLE_ENTITY = status(422);

  /**
   * 423 Locked (WebDAV, RFC4918)
   */
  HttpResponseExpectation SC_LOCKED = status(423);

  /**
   * 424 Failed Dependency (WebDAV, RFC4918)
   */
  HttpResponseExpectation SC_FAILED_DEPENDENCY = status(424);

  /**
   * 425 Unordered Collection (WebDAV, RFC3648)
   */
  HttpResponseExpectation SC_UNORDERED_COLLECTION = status(425);

  /**
   * 426 Upgrade Required (RFC2817)
   */
  HttpResponseExpectation SC_UPGRADE_REQUIRED = status(426);

  /**
   * 428 Precondition Required (RFC6585)
   */
  HttpResponseExpectation SC_PRECONDITION_REQUIRED = status(428);

  /**
   * 429 Too Many Requests (RFC6585)

View on GitHub (pinned to fb308bd8c3)

Solutions

Identify and fix the failed prerequisite request first, then retry the dependent operation.
Ensure parent resources/collections exist (create them in order) before dependent operations.
Make operations idempotent and ordered so a partial failure can be resumed rather than cascading.
Surface the root cause (the first failing request) instead of the 424 symptom.

Example fix

// before
client.request(POST, "/api/children")  // parent /api/parents does not exist -> 424
// after
client.request(POST, "/api/parents").compose(p -> client.request(POST, "/api/children"));

Defensive patterns

Strategy: fallback

Validate before calling

for (String path : requiredAncestors) {
  if (!exists(path)) createFirst(path); // ensure prerequisites before dependent calls
}

Type guard

boolean is424(HttpClientResponse resp) { return resp.statusCode() == 424; }

Try / catch

batchSend().onFailure(err -> {
  if (isCauseStatus(err, 424)) replayAfterFixingPrerequisite();
});

Prevention

Create parent resources before dependents
Order batch operations by dependency
Make each step idempotent so it can be safely retried
Log the first failing request, not just the 424

When it happens

Trigger: WebDAV multi-resource operations (e.g. MKCOL inside a path whose parent creation failed, or PROPPATCH on a resource that is part of a failed collection operation), or batch operations where one prerequisite request already failed with a 4xx.

Common situations: Batched WebDAV/REST operations where an earlier step failed; creating nested resources when a parent is missing; orchestration flows where one API call's failure cascades to dependents.

Related errors

AI-assisted analysis of eclipse-vertx/vert.x@fb308bd8c3 (2026-09-06). Data as JSON: /api/errors/73544e7e9a2abc5f. Report an issue: GitHub.