Throw client-safe errors for malformed date literals

[arunarw]

• Added or updated tests
• Documented user facing changes
• Updated CHANGELOG.md (skip for docs-only changes)

Changes

A malformed date is handled differently depending on whether it arrives as a query literal or as a variable. As a variable it is a client error. As a literal it is classified as a server fault: the message is masked as "Internal server error" and the exception is passed to the application's error reporter.

parseValue() → tryParsingDate() rethrows without a previous:

throw new $exceptionClass($exception->getMessage()); // previous = null → client-safe

parseLiteral() preserved it:

throw Error::createLocatedError($exception, $valueNode); // previous = InvalidFormatException

Carbon\Exceptions\InvalidFormatException does not implement ClientAware, so Error::__construct sets isClientSafe = false. FormattedError then masks the message, and ReportingErrorHandler forwards the exception to ExceptionHandler::report().

This affects Date, DateTime, DateTimeTz and DateTimeUtc, which all inherit parseLiteral from DateScalar.

The fix throws a client-safe error while keeping $valueNode, so locations is unchanged:

throw new Error($exception->getMessage(), $valueNode);

The added test lives in DateScalarTestBase, so it covers all four scalars. It fails on all four before the change:

4) Tests\Unit\Schema\Types\Scalars\DateTimeUtcTest::testThrowsClientSafeErrorIfParseLiteralInvalidDate
A malformed date literal is client misuse, so it must not be reported as a server error.
Failed asserting that false is true.

Tests: 4, Assertions: 8, Failures: 4.

The existing suite already covered parseValue with an invalid date and parseLiteral with a non-string node, but not parseLiteral with a malformed date string — which is why this went unnoticed.

We hit this on a Date query argument in production: roughly 6,200 reported exceptions from one client sending YYYY/MM/DD, each surfacing as a masked "Internal server error" rather than a usable validation message.

Breaking changes

None. Malformed literals still throw an Error with the same message and locations; only isClientSafe changes, so the error is no longer masked or reported. Valid values, parseValue and serialize are untouched.

[Copilot]

🟢 Approval recommended

The targeted implementation preserves locations, corrects error classification, and includes appropriate shared test coverage.

Pull request overview

Makes malformed date literals client-safe so GraphQL returns useful validation errors without server-side reporting.

Changes:

• Wraps parsing failures in client-safe GraphQL errors while preserving source locations.
• Adds coverage for all four date scalar types.
• Documents the fix in the changelog.

File summaries

File	Description
src/Schema/Types/Scalars/DateScalar.php	Makes malformed literal errors client-safe.
tests/Unit/Schema/Types/Scalars/DateScalarTestBase.php	Verifies client-safe errors across date scalars.
CHANGELOG.md	Records the corrected behavior.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.