Implement Exception Hierarchy For Better Error Handling #78

Ref34t · 2025-09-01T13:19:00Z

Summary
Implements exception hierarchy to improve error handling across the WordPress AI Client ecosystem, directly addressing feedback from PR 2 in https://github.com/WordPress/wp-ai-client

Changes

New Exception Classes

AiClientExceptionInterface - Base interface for catch-all exception handling
NetworkException - HTTP transport errors, connection failures, timeouts
RequestException - API authentication failures, rate limiting, malformed requests
InvalidArgumentException - Project-scoped extension of \InvalidArgumentException
RuntimeException - Project-scoped extension of \RuntimeException

Updated Code

Updated existing exception usage in AiClient.php, GenerativeAiResult.php, FunctionResponse.php
Modified ResponseException to extend RequestException for better categorization
Added comprehensive test coverage

Benefits

Unified Exception Handling:

try {
    $result = AiClient::prompt('Generate content')->generateText();
} catch (AiClientExceptionInterface $e) {
    // Catches ALL AI Client exceptions
}

Better Error Categorization:

Network issues → NetworkException
API/Auth issues → RequestException
Invalid arguments → InvalidArgumentException

Related

Addresses feedback from 2 review comments about improving exception handling for wp-ai-client integration. https://github.com/WordPress/wp-ai-client

Ref34t · 2025-09-01T13:28:41Z

@felixarntz This implements the exception hierarchy you suggested in PR 2 in the wp-ai-client review. Now developers can catch all AI Client exceptions with catch (AiClientExceptionInterface $e) for unified error handling, while still having specific exception types for different error categories (network, request, validation). The implementation is minimal and focused - exactly what was requested for better WP-ai-client integration.

felixarntz

@Ref34t Thank you for getting this started!

A few points of feedback below, and one higher-level point here: I think we should put the exceptions into specific directories. For example:

InvalidArgumentException and RuntimeException into src/Common/Exception
NetworkException and RequestException into src/Providers/Http/Exception (where we already have ResponseException)

@JasonTheAdams It would be great to get your review as well - including regarding my own feedback.

src/Exceptions/NetworkException.php

src/Exceptions/RequestException.php

src/Providers/Http/Exception/ResponseException.php

JasonTheAdams · 2025-09-02T15:08:57Z

I agree with @felixarntz! I like the direction, but we need to see these exceptions being used in a few places to indicate their concrete usage.

github-actions · 2025-09-02T15:09:07Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @mohamed.khaled@9hdigital.com.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: mohamed.khaled@9hdigital.com.

Co-authored-by: felixarntz <flixos90@git.wordpress.org>
Co-authored-by: JasonTheAdams <jason_the_adams@git.wordpress.org>
Co-authored-by: Ref34t <mokhaled@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Ref34t · 2025-09-02T22:03:53Z

@felixarntz @JasonTheAdams
I've spent some time refactoring and improving the enhancements, you can see below what I did:

Architectural Reorganization

Moved exceptions to proper directories:

InvalidArgumentException & RuntimeException → src/Common/Exception/
NetworkException & RequestException → src/Providers/Http/Exception/
Updated 50+ import statements across the entire codebase

Concrete Usage Examples

NetworkException: PSR-18 network error handling in HttpTransporter::send()
RequestException: 400 Bad Request response handling in HttpTransporter::send()
ResponseException: Missing API data handling in OpenAiModelMetadataDirectory
InvalidArgumentException: 50+ validation locations throughout codebase
RuntimeException: 40+ operational error locations throughout codebase

Proper Inheritance

Fixed inheritance relationships:

RequestException extends InvalidArgumentException (for bad request data validation)
ResponseException extends RuntimeException (for unexpected provider responses)
NetworkException extends RuntimeException (for network connectivity issues)

Enhanced Developer Experience (Static factory methods suggestion)

"Simply adding static from* methods to the various *Exception classes"

RequestException (3 methods):

RequestException::fromInvalidParam('OpenAI', 'temperature', 'Must be between 0 and 2');
RequestException::fromBadRequestResponse('OpenAI', $response);
RequestException::fromBadRequestToUri($uri, 'Invalid  JSON payload');

ResponseException (4 methods):

ResponseException::fromMissingData('OpenAI', 'data');
ResponseException::fromUnexpectedStructure('OpenAI', 'array', 'string');
ResponseException::fromMalformedResponse('OpenAI', 'Invalid JSON format');
ResponseException::fromParsingFailure('OpenAI', 'model list', $jsonException);

NetworkException (5 methods):

NetworkException::fromPsr18NetworkException($uri, $networkException);
NetworkException::fromConnectionFailure($uri, 'Connection refused');
NetworkException::fromTimeout($uri, 'request', 30);
NetworkException::fromDnsFailure('api.openai.com');
NetworkException::fromSslError($uri, 'Certificate  validation failed');

Kindly review and let me know if you have any concerned

JasonTheAdams

Thanks, @Ref34t! I'm not sure I see the point in creating our own InvalidArgumentException and RuntimeException classes. Do you, @felixarntz?

felixarntz · 2025-09-02T23:20:03Z

@JasonTheAdams I do actually. It's simply about providing classes that can implement a common interface to identify "this is a specific exception from our PHP AI Client SDK".

Consuming code can then decide whether they want to catch e.g. RuntimeException and/or InvalidArgumentException or whether they want to do a single catch-all for "known" exceptions from our SDK only by catching AiClientExceptionInterface.

JasonTheAdams · 2025-09-03T15:44:17Z

I like that, @felixarntz! Admittedly, I hadn't noticed the common Interface. I like that idea of being able to catch exceptions thrown by this package.

As a note, I think we should update the AGENTS.md to include a note that all exceptions should use our own, including primitives, and if a primitive doesn't exist it should be created. Not sure if we should add this elsewhere, too. If we're going down this road it's important that we're consistent.

JasonTheAdams

I'm tracking now, @Ref34t! Good work!

I don't think we need all these static methods. As far as I can tell, there all used only one time. If that's the case, the abstraction isn't necessary and we can just let the implementing code determine the code, message, and such.

src/Common/Exception/InvalidArgumentException.php

felixarntz

@Ref34t @JasonTheAdams I do think some of the static methods are useful - just not all of them.

Per my previous feedback, @Ref34t it would be great if you could review the codebase for where exceptions are thrown and update these exceptions to use the new exception classes and new static methods if applicable.

We should not introduce any exception classes or any static methods that aren't used anywhere - I think that's a good guiding principle. Therefore it's important that we update any existing exceptions to use the new approach, and if there are none for a specific exception or static method, we know it's not useful, at least not at this point.

Ref34t · 2025-09-04T15:47:31Z

very interesting Convo Champs @felixarntz @JasonTheAdams 🥇
I'll work it this today and bring the best from it based on my idea and your thoughts

…and PromptBuilder now use project-scoped InvalidArgumentException and RuntimeException for better error categorization and unified exception handling

…hp and HTTP Request/Response DTOs now use project-scoped exception classes for unified error handling

…romBadResponse() based on real usage in ResponseUtil, remove unused static methods keeping only those actually used in codebase

…eption

…rException

…rrors

JasonTheAdams

This is looking good to me! Thanks, @Ref34t!

felixarntz

A few more points of follow up feedback. This is getting close though.

One question I have for both of you @Ref34t @JasonTheAdams

felixarntz · 2025-09-23T02:22:35Z

src/Providers/Http/Exception/RequestException.php

+     *
+     * @var RequestInterface|null
+     */
+    private ?RequestInterface $request = null;


We should not store the lower-level PSR RequestInterface in RequestException class and its child classes - at the very least we shouldn't expose it publicly. We already have our own Request DTO for this purpose, so all public APIs should rely on that.

Can we change this accordingly here and in NetworkException please?

The only thing we'll want to be sure of, here, is that a PSR-7 RequestInterface is always converted to our Request DTO before it's passed to the exception. This is likely not an issue, but the only caveat that came to mind.

felixarntz · 2025-09-23T02:22:49Z

src/Providers/Http/Exception/RequestException.php

+     * @return RequestInterface
+     * @throws \RuntimeException If no request is available (when using deprecated fromBadRequestToUri)
+     */
+    public function getRequest(): RequestInterface


See above, this should use our Request DTO instead.

felixarntz · 2025-09-23T02:23:28Z

src/Providers/Http/Exception/RequestException.php

+    /**
+     * Creates a RequestException from a bad request.
+     *
+     * @since n.e.x.t
+     *
+     * @param RequestInterface $request The request that failed.
+     * @param string $errorDetail Details about what made the request bad.
+     * @return self
+     */
+    public static function fromBadRequest(
+        RequestInterface $request,
+        string $errorDetail = 'Invalid request parameters'
+    ): self {
+        $message = sprintf('Bad request to %s (400): %s', (string) $request->getUri(), $errorDetail);
+
+        $exception = new self($message);
+        $exception->request = $request;
+        return $exception;
+    }
+
+    /**
+     * Creates a RequestException from a bad request to a specific URI.
+     *
+     * @since n.e.x.t
+     *
+     * @param string $uri The URI that was requested.
+     * @param string $errorDetail Details about what made the request bad.
+     * @return self
+     *
+     * @deprecated Use fromBadRequest() with RequestInterface for PSR-18 compliance
+     */
+    public static function fromBadRequestToUri(string $uri, string $errorDetail = 'Invalid request parameters'): self
+    {
+        return new self(sprintf('Bad request to %s (400): %s', $uri, $errorDetail));
+    }


What's the rationale for having these two methods here rather than on ClientException, which is explicitly meant for 4xx errors?

got it. resolved

felixarntz · 2025-09-23T02:27:29Z

src/Providers/Http/Exception/RequestException.php

+ *
+ * @since n.e.x.t
+ */
+class RequestException extends InvalidArgumentException implements RequestExceptionInterface


This is something @JasonTheAdams discussed but still didn't fully find a solution for: It doesn't feel right that a generic RequestException extends InvalidArgumentException. Some request exceptions fit into that (e.g. for 400 errors), others fit better to extend RuntimeException (such as 500 errors).

Brainstorming a bit: Do we even need the base RequestException class? As far as I can tell, we could have only the more specific ClientException, NetworkException, RedirectException, and ServerException, and be fine. Then ClientException could extend InvalidArgumentException while the other three could extend RuntimeException.

IMO this would clean things up nicely. What do you both think?

Ah, a couple notes here. First, I agree that this shouldn't extend InvalidArgumentException. I think it should either extend our Exception primitive or RuntimeException.

If you recall, @felixarntz, we made RequestException a class instead of an interface so that it could be used inside of Providers/Models when there isn't a status code but we are in "request" territory. Do you not think we need this anymore?

@JasonTheAdams Hmm, right. I'm not sure we need it anymore. I think it would be totally reasonable to use (our) InvalidArgumentException in cases of invalid arguments that we catch before an actual request. ClientException (for actual 4xx errors from a request) would extend InvalidArgumentException, so a developer could still catch InvalidArgumentException and be sure to get any relevant scenarios of "invalid arguments" (whether caught by our code or by the actual API).

Therefore I'm leaning towards getting rid of RequestException.

That's fine be me. Do we want to turn RequestException into an interface so folks can catch any of the subsequent exceptions easily?

I think we can leave that out for now, we can always add it later if we feel it's reasonable. I feel most people will anyway just want to catch any of our SDK's exceptions, or maybe split by InvalidArgumentException and RuntimeException, or something like that.

src/Providers/Http/Exception/RequestException.php

src/Providers/Http/Exception/ResponseException.php

Add ErrorMessageExtractor utility to centralize parsing of common API error response formats across exception classes. Handles standard patterns like { "error": { "message": "..." } }, { "error": "..." }, and { "message": "..." }. Implement fromPsrRequest static factory method in Request DTO to support PSR-7 to internal DTO conversion for exception context storage.

…est DTOs

Ref34t · 2025-09-26T16:27:32Z

@felixarntz Here is the summary of the iteration I did:

Build centralized error message extraction utility (4314134)

What: Created a centralized ErrorMessageExtractor utility class
Purpose: Standardizes parsing of API error responses across different formats
Key Features:
- Handles common patterns: {"error": {"message": "..."}}, {"error": "..."}, {"message": "..."}
- Added fromPsrRequest factory method to Request DTO for PSR-7 conversion
Files: src/Providers/Http/DTO/Request.php, src/Providers/Http/Utilities/ErrorMessageExtractor.php

Implement semantic exception hierarchy with proper inheritance patterns (0f18425)

What: Restructured exception classes with proper object-oriented inheritance
Key Changes:
- Enhanced ClientException with more sophisticated error handling
- Refactored NetworkException for better network-specific error management
- Removed RequestException

Update exception classes to use centralized error extraction and Request DTOs (2867cbc)

What: Integrated the new ErrorMessageExtractor utility across exception classes
Key Changes:
- Simplified RedirectException, ResponseException, and ServerException
- Reduced code duplication by using centralized error extraction
- Leveraged Request DTOs for consistent data handling

Update exception tests for new hierarchy structure (e16fba4)

What: Updated test suite to match the new exception hierarchy
Purpose: Ensured test coverage remains accurate after architectural changes
Files: tests/unit/Exceptions/ExceptionsTest.php

felixarntz

@Ref34t Thank you for the iterations. A few more follow-up comments below.

src/Providers/Http/Util/ResponseUtil.php

src/Providers/Http/Exception/ClientException.php

felixarntz · 2025-09-26T21:11:52Z

src/Providers/Http/Exception/ClientException.php

+    /**
+     * Creates a ClientException from a 400 Bad Request response.
+     *
+     * @since n.e.x.t
+     *
+     * @param string $errorDetail Details about what made the request bad.
+     * @return self
+     */
+    public static function fromBadRequestResponse(string $errorDetail = 'Invalid request parameters'): self
+    {
+        $message = sprintf('Bad request (400): %s', $errorDetail);
+        return new self($message, 400);
+    }
+
+    /**
+     * Creates a ClientException from a bad request.
+     *
+     * @since n.e.x.t
+     *
+     * @param RequestInterface $psrRequest The PSR-7 request that failed.
+     * @param string $errorDetail Details about what made the request bad.
+     * @return self
+     */
+    public static function fromBadRequest(
+        RequestInterface $psrRequest,
+        string $errorDetail = 'Invalid request parameters'
+    ): self {
+        $request = Request::fromPsrRequest($psrRequest);
+        $message = sprintf('Bad request to %s (400): %s', $request->getUri(), $errorDetail);
+
+        $exception = new self($message, 400);
+        $exception->request = $request;
+        return $exception;
+    }
+
+    /**
+     * Creates a ClientException from a bad request to a specific URI.
+     *
+     * @since n.e.x.t
+     *
+     * @param string $uri The URI that was requested.
+     * @param string $errorDetail Details about what made the request bad.
+     * @return self
+     *
+     * @deprecated Use fromBadRequest() with RequestInterface for better type safety
+     */
+    public static function fromBadRequestToUri(string $uri, string $errorDetail = 'Invalid request parameters'): self
+    {
+        return new self(sprintf('Bad request to %s (400): %s', $uri, $errorDetail), 400);
+    }


Why do we need all these? Where are they used?

I think it would be sufficient to have the single fromClientErrorResponse below.

We can easily centralize any special handling we want to have for 400 errors, e.g. in that method you could add a check that changes the message to Bad request (400): %s instead. Even better, you could have a short map of a few important error codes and their reasons, similar to how you have in fromRedirectResponse.

On another note: Let's be consistent with the error messages - some messages here include the URI while others don't.

@felixarntz Done! Removed all unnecessary static methods in commit 7bbaadd.

Now ClientException has only fromClientErrorResponse() with focused status code mapping (400, 401, 403, 404, 422, 429) similar to RedirectException. All error messages are now consistent without URI discrepancies.

The three removed methods were unused and creating unnecessary complexity. Thanks for the simplification guidance!

One follow up feedback below, I think this is still not the message format I suggested above.

src/Providers/Http/Exception/ResponseException.php

src/Providers/Http/Exception/ServerException.php

src/Providers/Http/Util/ResponseUtil.php

src/Providers/OpenAiCompatibleImplementation/AbstractOpenAiCompatibleImageGenerationModel.php

src/Providers/Http/Exception/ResponseException.php

src/Providers/OpenAiCompatibleImplementation/AbstractOpenAiCompatibleTextGenerationModel.php

…ations

… with status mapping

…fromMissingData method

…names

felixarntz

@Ref34t Thank you for the iterations, this looks pretty much good to go!

Just a few last points, but those are quick to address, so I can do that inline and merge.

felixarntz · 2025-09-30T18:45:50Z

src/Providers/Http/Exception/ClientException.php

+            429 => 'Too Many Requests',
+        ];
+
+        $statusText = $statusTexts[$statusCode] ?? 'Client Error';


With this, it can lead to some weird messages like this: Client error (405 Client Error): Request was rejected due to client-side issue

Instead of this, can we change the message completely depending on whether a specific status text is set or not?

Something like:

if (isset($statusTexts[$statusCode])) { $errorMessage = sprintf('%s (%d)', $statusTexts[$statusCode], $statusCode); } else { $errorMessage = sprintf('Client error (%d): Request was rejected due to client-side issue', $statusCode); }

felixarntz · 2025-09-30T18:46:29Z

src/Providers/Http/Exception/RedirectException.php

+            308 => 'Permanent Redirect',
+        ];
+
+        $statusText = $statusTexts[$statusCode] ?? 'Redirect';


Can we do the same approach here that I suggested above in ClientException?

felixarntz · 2025-09-30T18:46:40Z

src/Providers/Http/Exception/ServerException.php

+            507 => 'Insufficient Storage',
+        ];
+
+        $statusText = $statusTexts[$statusCode] ?? 'Server Error';


And same here.

Ref34t marked this pull request as ready for review September 1, 2025 13:28

felixarntz added the [Type] Enhancement A suggestion for improvement. label Sep 1, 2025

felixarntz reviewed Sep 1, 2025

View reviewed changes

src/Exceptions/NetworkException.php Outdated Show resolved Hide resolved

src/Exceptions/RequestException.php Outdated Show resolved Hide resolved

src/Providers/Http/Exception/ResponseException.php Outdated Show resolved Hide resolved

felixarntz mentioned this pull request Sep 2, 2025

Enhancement: Improve Error Handling Developer Experience #60

Closed

JasonTheAdams self-requested a review September 2, 2025 14:50

JasonTheAdams reviewed Sep 2, 2025

View reviewed changes

JasonTheAdams mentioned this pull request Sep 3, 2025

Development roadmap #8

Open

20 tasks

JasonTheAdams requested changes Sep 3, 2025

View reviewed changes

src/Common/Exception/InvalidArgumentException.php Outdated Show resolved Hide resolved

felixarntz reviewed Sep 3, 2025

View reviewed changes

Mohamed Khaled added 12 commits September 5, 2025 19:07

Implement simplified exception hierarchy for better error handling

19b0b50

Fix code style violations

f1b23d3

Implement exception hierarchy reorganization with static factory methods

a22c94e

Fix code style violations in exception classes

98a84cf

Fix line length violations in exception factory methods

28ce137

Fix function declaration brace placement

227498b

Update @SInCE tags from 0.2.0 to n.e.x.t

eb9686d

Update core files to use custom exception classes - ProviderRegistry …

f158e71

…and PromptBuilder now use project-scoped InvalidArgumentException and RuntimeException for better error categorization and unified exception handling

Update HTTP and File DTOs to use custom exceptions - Files/DTO/File.p…

9eac85b

…hp and HTTP Request/Response DTOs now use project-scoped exception classes for unified error handling

Implement usage-driven exception hierarchy - Add ResponseException::f…

1f2fc0e

…romBadResponse() based on real usage in ResponseUtil, remove unused static methods keeping only those actually used in codebase

Add exception handling requirements to coding standards

c1aede5

Implement usage-driven exception hierarchy with custom classes

f901fce

Ref34t force-pushed the feature/exception-hierarchy branch from 722138b to f901fce Compare September 5, 2025 16:15

Fix File exception handling to use specific MimeType exceptions

048d889

Mohamed Khaled added 6 commits September 11, 2025 17:37

Implement exception hierarchy improvements

a6bbaf2

Update Anthropic and Google ModelMetadataDirectory to use ResponseExc…

7c742aa

…eption

Implement ClientException for 4xx responses in ResponseUtil

4a69461

Implement complete exception hierarchy with ClientException and Serve…

8ab52c3

…rException

Update tests to expect new exception hierarchy

beb17e1

Enhance ResponseException with semantic factory methods for parsing e…

44c8a4f

…rrors

Ref34t requested a review from felixarntz September 12, 2025 06:57

JasonTheAdams approved these changes Sep 22, 2025

View reviewed changes

felixarntz reviewed Sep 23, 2025

View reviewed changes

Mohamed Khaled added 4 commits September 25, 2025 16:40

Implement semantic exception hierarchy with proper inheritance patterns

0f18425

Update exception classes to use centralized error extraction and Requ…

2867cbc

…est DTOs

Update exception tests for new hierarchy structure

e16fba4

Ref34t requested review from JasonTheAdams and felixarntz September 26, 2025 16:27

felixarntz reviewed Sep 26, 2025

View reviewed changes

Mohamed Khaled added 7 commits September 29, 2025 23:02

Remove special 400 handling from ResponseUtil

5e765f8

Rename fromClientError to fromClientErrorResponse and fix test expect…

01bafd9

…ations

Remove unnecessary ClientException static methods and add status mapping

7bbaadd

Remove unused RequestInterface import from ClientException

4e5529c

Remove ResponseException::fromBadResponse and enhance ServerException…

4cc060b

… with status mapping

Complete exception hierarchy with indexed field names and simplified …

436549f

…fromMissingData method

Fix test expectations for new exception hierarchy with indexed field …

8cde241

…names

Ref34t requested a review from felixarntz September 29, 2025 20:55

felixarntz approved these changes Sep 30, 2025

View reviewed changes

felixarntz added 2 commits September 30, 2025 11:50

Merge branch 'trunk' into feature/exception-hierarchy

8dd8719

Enhance HTTP request exception message format.

ef9a3bb

felixarntz merged commit f9acb52 into WordPress:trunk Sep 30, 2025
5 checks passed

felixarntz mentioned this pull request Oct 1, 2025

Enhance exception API for response exceptions from invalid values by including concrete field name #102

Merged

Uh oh!

Implement Exception Hierarchy For Better Error Handling #78

Implement Exception Hierarchy For Better Error Handling #78

Uh oh!

Conversation

Ref34t commented Sep 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ref34t commented Sep 1, 2025

Uh oh!

felixarntz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JasonTheAdams commented Sep 2, 2025

Uh oh!

github-actions bot commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Unlinked Accounts

Uh oh!

Ref34t commented Sep 2, 2025

Uh oh!

JasonTheAdams left a comment

Choose a reason for hiding this comment

Uh oh!

felixarntz commented Sep 2, 2025

Uh oh!

JasonTheAdams commented Sep 3, 2025

Uh oh!

JasonTheAdams left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

felixarntz left a comment

Choose a reason for hiding this comment

Uh oh!

Ref34t commented Sep 4, 2025

Uh oh!

JasonTheAdams left a comment

Choose a reason for hiding this comment

Uh oh!

felixarntz left a comment

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!

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!

Uh oh!

Uh oh!

Uh oh!

Ref34t commented Sep 26, 2025

Uh oh!

felixarntz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ref34t commented Sep 1, 2025 •

edited

Loading

github-actions bot commented Sep 2, 2025 •

edited

Loading