feat(connectors): add S3 sink connector by atharvalade · Pull Request #3103 · apache/iggy

atharvalade · 2026-04-13T06:52:04Z

Which issue does this PR close?

Rationale

Iggy lacks a native way to write stream messages to Amazon S3 and S3-compatible stores (MinIO, Cloudflare R2, Backblaze B2, DigitalOcean Spaces). This is a frequently requested capability for data lake ingestion and long-term archival pipelines.

What changed?

There was no connector for persisting Iggy messages to object storage. Users had to build custom consumers and upload logic to get data into S3.

This PR adds a new iggy_connector_s3_sink crate that implements the Sink trait. It buffers messages in-memory per stream/topic/partition, rotates files by size or message count, renders S3 keys from a configurable path template ({stream}/{topic}/{date}/{hour}/...), and uploads with retry + exponential backoff. Supports json_lines, json_array, and raw output formats with optional Iggy metadata and header embedding. Uses rust-s3 (already in workspace) with path-style addressing auto-enabled for custom endpoints.

Key implementation details:

6 source modules: lib.rs (config + entry point), client.rs (S3 client init + bucket verification), buffer.rs (in-memory accumulation + rotation logic), formatter.rs (JSON/raw output + metadata/header inclusion), path.rs (template engine for S3 keys with offset-based filenames), sink.rs (Sink trait: open/consume/close lifecycle)
36 unit tests covering config deserialization, buffer rotation, path template rendering, all output formats, credential validation, and edge cases
CI integration: added to _build_rust_artifacts.yml and edge-release.yml for cdylib plugin builds and release notes
Error handling: warnings logged on invalid config fallbacks, explicit buffer management on upload failure, close() warns if S3 client was never initialized
End-to-end tested locally with MinIO in Docker, Iggy server, CLI producer, and connector runtime — verified messages flow from Iggy stream into S3 bucket as properly formatted JSON

Local Execution

Passed
Pre-commit hooks ran
Full CI checklist passed locally:
- cargo fmt --check -- pass
- cargo clippy --tests -D warnings -- pass (zero warnings)
- cargo test -p iggy_connector_s3_sink -- 36/36 pass
- markdownlint --check -- pass
- trailing-whitespace -- pass
- trailing-newline -- pass
- license-headers -- pass

AI Usage

Opus 4.6
used for scaffolding boilerplate and initial file structure, all logic was reviewed and iterated manually
Verified through full local compilation, 36 unit tests, clippy with -D warnings, and end-to-end testing with MinIO Docker + Iggy server + CLI producer + connector runtime
Yes

Here are all the relevant screenshots:

MinIO Docker container running and accessible at localhost:9000
MinIO web console showing the created iggy-test bucket
Iggy server started with root credentials configured
Iggy CLI creating stream application_logs and topic api_requests
Iggy CLI sending test messages to the topic
Connector runtime loading the S3 sink plugin and connecting to MinIO
Connector runtime consuming messages and uploading to S3
MinIO console showing the uploaded .jsonl file in the correct path structure (application_logs/api_requests/{date}/{hour}/)
Contents of the uploaded file showing properly formatted JSON lines with metadata (offset, timestamp, stream, topic, partition_id, payload)
All 36 unit tests passing
cargo clippy --tests -D warnings passing with zero warnings

codecov · 2026-04-13T06:59:48Z

Codecov Report

❌ Patch coverage is 71.29032% with 267 lines in your changes missing coverage. Please review.
✅ Project coverage is 13.93%. Comparing base (7aa4539) to head (bb233a2).

Files with missing lines	Patch %	Lines
core/connectors/sinks/s3_sink/src/sink.rs	0.00%	120 Missing ⚠️
core/connectors/sinks/s3_sink/src/lib.rs	69.60%	69 Missing ⚠️
core/connectors/sinks/s3_sink/src/formatter.rs	83.40%	38 Missing and 3 partials ⚠️
core/connectors/sinks/s3_sink/src/client.rs	75.00%	21 Missing and 6 partials ⚠️
core/connectors/sinks/s3_sink/src/path.rs	93.96%	4 Missing and 3 partials ⚠️
core/connectors/sinks/s3_sink/src/buffer.rs	97.32%	3 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             master    #3103       +/-   ##
=============================================
- Coverage     74.16%   13.93%   -60.23%     
  Complexity      943      943               
=============================================
  Files          1237     1241        +4     
  Lines        112641    98557    -14084     
  Branches      89201    75148    -14053     
=============================================
- Hits          83536    13736    -69800     
- Misses        26309    84676    +58367     
+ Partials       2796      145     -2651

Components	Coverage Δ
Rust Core	`1.25% <71.29%> (-74.05%)`	⬇️
Java SDK	`58.44% <ø> (ø)`
C# SDK	`19.71% <ø> (-50.94%)`	⬇️
Python SDK	`81.43% <ø> (ø)`
Node SDK	`91.53% <ø> (+0.12%)`	⬆️
Go SDK	`13.11% <ø> (-26.80%)`	⬇️

Files with missing lines	Coverage Δ
core/connectors/sinks/s3_sink/src/buffer.rs	`97.32% <97.32%> (ø)`
core/connectors/sinks/s3_sink/src/path.rs	`93.96% <93.96%> (ø)`
core/connectors/sinks/s3_sink/src/client.rs	`75.00% <75.00%> (ø)`
core/connectors/sinks/s3_sink/src/formatter.rs	`83.40% <83.40%> (ø)`
core/connectors/sinks/s3_sink/src/lib.rs	`69.60% <69.60%> (ø)`
core/connectors/sinks/s3_sink/src/sink.rs	`0.00% <0.00%> (ø)`

... and 829 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

github-actions · 2026-04-21T00:48:25Z

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.

If you need a review, please ensure CI is green and the PR is rebased on the latest master. Don't hesitate to ping the maintainers - either @core on Discord or by mentioning them directly here on the PR.

Thank you for your contribution!

slbotbm

I left some comments.
Also, do you plan to support using parquet files as well in the future?

slbotbm · 2026-04-21T14:12:55Z

I also feel data loss due to maximum retries being exceeded should be mentioned in readme.md as a precaution.

atharvalade · 2026-04-24T15:17:10Z

I left some comments. Also, do you plan to support using parquet files as well in the future?

oh yes absolutely.. parquet support is on the roadmap as a future output_format option

atharvalade · 2026-04-24T15:19:36Z

I also feel data loss due to maximum retries being exceeded should be mentioned in readme.md as a precaution.

I agree, I'll add that

github-actions · 2026-05-06T00:50:04Z

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.

If you need a review, please ensure CI is green and the PR is rebased on the latest master. Don't hesitate to ping the maintainers - either @core on Discord or by mentioning them directly here on the PR.

Thank you for your contribution!

github-actions · 2026-05-14T00:58:26Z

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.

If you need a review, please ensure CI is green and the PR is rebased on the latest master. Don't hesitate to ping the maintainers - either @core on Discord or by mentioning them directly here on the PR.

Thank you for your contribution!

hubcio · 2026-05-14T12:02:46Z

/ready

hubcio · 2026-05-20T17:30:56Z

+- Buffered uploads with configurable file rotation (by size or message count)
+- Multiple output formats: JSON Lines, JSON Array, Raw
+- Configurable path templates with variables for stream, topic, date, hour, partition
+- Deterministic S3 keys based on offset ranges for idempotent crash recovery


"deterministic S3 keys ... idempotent crash recovery" is false on three grounds:

path.rs:64 substitutes {timestamp} via Utc::now().timestamp_millis() at render time, so retries produce different keys

buffer.rs is in-memory only with no WAL, so a process restart cannot reproduce the same batch boundaries

runtime auto-commits offsets on poll (bug(connectors): PollingMessages auto-commit commits offsets before sink processing #2928) and the FFI return code is discarded (bug(connectors): consume() return value discarded in sink runtime #2927), so replay never happens anyway

either remove the claim, or remove {timestamp} from the template and document the in-memory loss path honestly.

Removed claim, documented honestly instead

hubcio · 2026-05-20T17:30:56Z

+- Deterministic S3 keys based on offset ranges for idempotent crash recovery
+- Optional metadata and header inclusion in output
+- Support for custom endpoints (MinIO, R2) and path-style addressing
+- Retry with exponential backoff on upload failures


"retry with exponential backoff" - code at sink.rs:260 is retry_delay * attempts, which is linear (1s, 2s, 3s). either update the doc to "linear backoff" or implement retry_delay * 2u32.pow(attempts - 1) with jitter. also AFAIR there is backoff in connectors SDK, please check it.

Now uses SDK exponential_backoff + jitter

hubcio · 2026-05-20T17:30:56Z

+
+## Data Delivery Guarantees
+
+This connector provides **at-least-once** delivery under normal operation. However, **data loss can occur** if all upload retries are exhausted (controlled by `max_retries`). When an upload fails after all retry attempts, the affected messages are dropped and an error is logged. Monitor your connector logs for `failed to upload` errors in production. Increase `max_retries` and `retry_delay` if transient S3 failures are common in your environment.


this paragraph claims at-least-once and then admits "data loss can occur" in the same sentence - that is self-contradictory. given #2927 + #2928, no sink connector can deliver at-least-once today. the canonical in-tree wording is http_sink/README.md:790-800 which honestly documents at-most-once and cites both bugs. recommend copying that section verbatim.

Replaced with http_sink's at-most-once wording, citing #2927/#2928

hubcio · 2026-05-20T17:30:56Z

+chrono = { workspace = true }
+dashmap = { workspace = true }
+humantime = { workspace = true }
+iggy_common = { workspace = true }


iggy_common is declared under [dependencies] but the only usage in this crate is formatter.rs:233-235 under #[cfg(test)]. move it to [dev-dependencies] so it does not bloat the cdylib build.

Moved to [dev-dependencies]

Correction to my earlier reply: iggy_common remains in [dependencies] (not [dev-dependencies]) because the header-serialization fix (your comment on formatter.rs:75) introduced runtime usage of HeaderKey, HeaderValue, and HeaderKind via serialize_headers at formatter.rs:124-169. The original premise (test-only) was accurate for v1 but is no longer true after the HeaderKind match dispatch was added

hubcio · 2026-05-20T17:30:56Z

+# under the License.
+
+[package]
+name = "iggy_connector_s3_sink"


missing publish = false. every other connector sink (postgres_sink, delta_sink, http_sink, elasticsearch_sink, stdout_sink) declares publish = false because they are cdylib plugins not meant for crates.io. without it the crate would publish on the next workspace release.

Added, matches all other sinks

hubcio · 2026-05-20T17:30:57Z

+        }
+
+        let mut state = self.state.lock().await;
+        state.messages_processed += messages.len() as u64;


state.messages_processed += messages.len() as u64 runs unconditionally outside the rotate loop, so when a mid-batch flush dropped N messages this counter still claims it processed them. upload_errors increments separately at :209. result: the close-log at :155-156 reports more messages processed than actually landed in S3. either decrement on drop or split into messages_buffered / messages_uploaded / messages_lost.

Split into messages_received / messages_uploaded / messages_lost

hubcio · 2026-05-20T17:30:57Z

+                // Reset buffer even on failure to prevent unbounded growth.
+                // Messages are lost but offsets will be re-delivered by the
+                // runtime on next poll since consume() returned Ok.
+                buffer.reset();


this is the worst data-loss path in the PR. on retry-exhaust the failure branch logs an error and then calls buffer.reset() at :214 to drop the messages, while consume at :126 still returns Ok(()). the comment at :211-213 claims "offsets will be re-delivered by the runtime on next poll since consume() returned Ok" - that is doubly false:

the runtime auto-commits offsets before consume runs (runtime/sink.rs:421 uses AutoCommitWhen::PollingMessages, see bug(connectors): PollingMessages auto-commit commits offsets before sink processing #2928), so the offset has already advanced past these messages by the time you return.

the runtime discards the consume FFI return code (runtime/sink.rs:585-593, see bug(connectors): consume() return value discarded in sink runtime #2927), so even returning Err wouldn't trigger retry today.

net result: a single transient S3 hiccup that exhausts max_retries (default 3) permanently loses every buffered message. the README at line 139 acknowledges this but still claims at-least-once on the same line.

minimum: drop the false comment, propagate Err to the runtime, and align the README with http_sink/README.md:790-800 (at-most-once + cite #2927 / #2928).

Removed false re-delivery comment, propagate error, aligned README with known runtime limitations

hubcio · 2026-05-20T17:30:57Z

+                        return Ok(());
+                    }
+                    attempts += 1;
+                    if attempts >= max_retries {


attempts starts at 0 and increments before the >= max_retries check, so max_retries = 3 yields 3 total attempts (2 retries past the initial one). this matches the postgres_sink pattern but the field name is misleading. either rename to max_attempts or use attempts > max_retries so the field name lines up with semantics.

Renamed to max_attempts for clarity

hubcio · 2026-05-20T17:30:57Z

+        let mut attempts = 0u32;
+
+        loop {
+            match bucket.put_object(s3_key, data).await {


the retry loop treats every non-2xx status uniformly. AWS permanent failures - AccessDenied (403), NoSuchBucket (404), InvalidBucketName (400), MalformedPolicy - get retried 3 times, wasting retry_delay * (1 + 2) = 3s before the final Err. classify retriable vs not: 5xx + 408 + 429 + 503 SlowDown -> retry; other 4xx -> fail fast.

Added is_retriable_status: only 5xx/408/429 retry, other 4xx fail fast

hubcio · 2026-05-20T17:30:57Z

+                    );
+                }
+            }
+            tokio::time::sleep(retry_delay * attempts).await;


retry_delay * attempts is linear backoff (1s, 2s, 3s), but the README at line 13 advertises exponential. either implement retry_delay * 2u32.pow(attempts - 1) with jitter, or update the doc to "linear".

separately, Duration::Mul<u32> panics on overflow - default config is safe but pathological values (e.g. retry_delay = "1h" + large max_retries) would panic. saturating_mul is cheap defensive practice.

Implemented true exponential with jitter, capped at 60s via SDK helpers

hubcio · 2026-05-20T17:43:48Z

/author

Write Iggy stream messages to Amazon S3 and S3-compatible stores with buffered uploads, configurable rotation, and deterministic offset-based keys.

…ctness DashMap per-partition buffers (no lock held during upload), contiguous buffer Vec<u8>+sidecar, SecretString credentials, HeaderKind-aware serialization, owned_value_to_serde_json, byte-concat JsonArray finalize, 20-digit offset padding, partition in filename, deterministic timestamps, strict config validation, .lost marker on flush failure, error propagation.

atharvalade · 2026-05-23T06:35:50Z

The biggest thing I caught was a credential leak where the derived Debug on S3Sink would dump the full AWS access key and secret key into logs whenever the struct got printed. I replaced that with a manual Debug impl that just shows the bucket name and added a regression test so it never sneaks back in. On the metrics side, the received count was being incremented after processing the batch, which meant if something failed halfway through you could lose track of how many messages actually got dropped. I moved that counter up front and added logic to correctly mark the unprocessed remainder as lost. I also cleaned up the dependency situation since once_cell was listed but never used, simd-json was only needed in tests but lived in regular deps, and the cargo-machete ignore list was papering over all of it.

The max_retries field got renamed to max_attempts with a serde alias so existing configs still work, and the README had a contradiction where it said timestamp was wall clock time when the code actually derives it from the first message in the buffer, so I fixed the docs to match reality. For the lost marker file that records data gaps, I routed it through the retry logic so a transient S3 hiccup does not silently eat your gap record. Then I wrote about twenty unit tests covering the pure functions like retry status classification, flush payload extraction, config validation, and the Debug redaction. Finally I stood up a full integration test suite using MinIO in a container that validates the sink actually writes jsonl to S3 with the correct path layout and rotates files properly when the message count threshold is hit.

/ready

codecov · 2026-05-23T06:37:14Z

Codecov Report

❌ Patch coverage is 71.29032% with 267 lines in your changes missing coverage. Please review.
✅ Project coverage is 18.27%. Comparing base (7aa4539) to head (cd1102b).
⚠️ Report is 36 commits behind head on master.

Files with missing lines	Patch %	Lines
core/connectors/sinks/s3_sink/src/sink.rs	0.00%	120 Missing ⚠️
core/connectors/sinks/s3_sink/src/lib.rs	69.60%	69 Missing ⚠️
core/connectors/sinks/s3_sink/src/formatter.rs	83.40%	38 Missing and 3 partials ⚠️
core/connectors/sinks/s3_sink/src/client.rs	75.00%	21 Missing and 6 partials ⚠️
core/connectors/sinks/s3_sink/src/path.rs	93.96%	4 Missing and 3 partials ⚠️
core/connectors/sinks/s3_sink/src/buffer.rs	97.32%	3 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             master    #3103       +/-   ##
=============================================
- Coverage     74.16%   18.27%   -55.89%     
  Complexity      943      943               
=============================================
  Files          1237     1241        +4     
  Lines        112641    98557    -14084     
  Branches      89201    75149    -14052     
=============================================
- Hits          83536    18010    -65526     
- Misses        26309    80107    +53798     
+ Partials       2796      440     -2356

Components	Coverage Δ
Rust Core	`1.25% <71.29%> (-74.05%)`	⬇️
Java SDK	`58.44% <ø> (ø)`
C# SDK	`70.12% <ø> (-0.53%)`	⬇️
Python SDK	`81.43% <ø> (ø)`
Node SDK	`91.53% <ø> (+0.12%)`	⬆️
Go SDK	`39.91% <ø> (ø)`

Files with missing lines	Coverage Δ
core/connectors/sinks/s3_sink/src/buffer.rs	`97.32% <97.32%> (ø)`
core/connectors/sinks/s3_sink/src/path.rs	`93.96% <93.96%> (ø)`
core/connectors/sinks/s3_sink/src/client.rs	`75.00% <75.00%> (ø)`
core/connectors/sinks/s3_sink/src/formatter.rs	`83.40% <83.40%> (ø)`
core/connectors/sinks/s3_sink/src/lib.rs	`69.60% <69.60%> (ø)`
core/connectors/sinks/s3_sink/src/sink.rs	`0.00% <0.00%> (ø)`

... and 712 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

atharvalade · 2026-05-24T20:13:51Z

/author

github-actions · 2026-06-01T01:08:46Z

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.

If you need a review, please ensure CI is green and the PR is rebased on the latest master. Don't hesitate to ping the maintainers - either @core on Discord or by mentioning them directly here on the PR.

Thank you for your contribution!

github-actions Bot added the S-stale Inactive issue or pull request label Apr 21, 2026

slbotbm reviewed Apr 21, 2026

View reviewed changes

Comment thread core/connectors/sinks/s3_sink/src/lib.rs Outdated

Comment thread core/connectors/sinks/s3_sink/src/sink.rs Outdated

Comment thread core/connectors/sinks/s3_sink/src/client.rs Outdated

Comment thread core/connectors/sinks/s3_sink/src/lib.rs Outdated

github-actions Bot removed the S-stale Inactive issue or pull request label Apr 22, 2026

atharvalade force-pushed the feat/s3-sink-connector branch from 96ed8d1 to 87e0cc0 Compare April 24, 2026 15:16

atharvalade force-pushed the feat/s3-sink-connector branch from 0a37619 to 00fc2df Compare April 28, 2026 17:34

github-actions Bot added S-stale Inactive issue or pull request and removed S-stale Inactive issue or pull request labels May 6, 2026

github-actions Bot added the S-stale Inactive issue or pull request label May 14, 2026

github-actions Bot added S-waiting-on-review PR is waiting on a reviewer and removed S-stale Inactive issue or pull request labels May 14, 2026

hubcio requested changes May 20, 2026

View reviewed changes

github-actions Bot added S-waiting-on-author PR is waiting on author response and removed S-waiting-on-review PR is waiting on a reviewer labels May 20, 2026

atharvalade added 3 commits May 22, 2026 22:12

feat(connectors): add S3 sink connector

53b231b

Write Iggy stream messages to Amazon S3 and S3-compatible stores with buffered uploads, configurable rotation, and deterministic offset-based keys.

fix(connectors): improve S3 sink error handling and observability

149d215

refactor(connectors): address S3 sink PR review feedback

2c3a2eb

atharvalade force-pushed the feat/s3-sink-connector branch from 980d64d to c0a5722 Compare May 23, 2026 05:17

refactor(connectors): address S3 sink review feedback v2

099de6f

atharvalade force-pushed the feat/s3-sink-connector branch from c0a5722 to 099de6f Compare May 23, 2026 05:19

atharvalade force-pushed the feat/s3-sink-connector branch from f15cc53 to 6cfac12 Compare May 23, 2026 06:02

fix(s3_sink): harden security, metrics, deps and add integration tests

bb233a2

github-actions Bot added S-waiting-on-review PR is waiting on a reviewer and removed S-waiting-on-author PR is waiting on author response labels May 23, 2026

atharvalade added 4 commits May 24, 2026 12:12

style: fix rustfmt formatting in integration tests

eb68fea

style: fix dependency sort order in integration Cargo.toml

824a6bb

fix(integration): use runtime config pattern for S3 sink tests

6f0b906

fix(integration): override s3 prefix to empty in test fixture

cd1102b

github-actions Bot added S-waiting-on-author PR is waiting on author response and removed S-waiting-on-review PR is waiting on a reviewer labels May 24, 2026

github-actions Bot added the S-stale Inactive issue or pull request label Jun 1, 2026


		## Data Delivery Guarantees

		This connector provides at-least-once delivery under normal operation. However, data loss can occur if all upload retries are exhausted (controlled by `max_retries`). When an upload fails after all retry attempts, the affected messages are dropped and an error is logged. Monitor your connector logs for `failed to upload` errors in production. Increase `max_retries` and `retry_delay` if transient S3 failures are common in your environment.

Conversation

atharvalade commented Apr 13, 2026

Which issue does this PR close?

Rationale

What changed?

Local Execution

AI Usage

Uh oh!

codecov Bot commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

github-actions Bot commented Apr 21, 2026

Uh oh!

slbotbm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

slbotbm commented Apr 21, 2026

Uh oh!

atharvalade commented Apr 24, 2026

Uh oh!

atharvalade commented Apr 24, 2026

Uh oh!

github-actions Bot commented May 6, 2026

Uh oh!

github-actions Bot commented May 14, 2026

Uh oh!

hubcio commented May 14, 2026

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!

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!

hubcio commented May 20, 2026

Uh oh!

atharvalade commented May 23, 2026

Uh oh!

codecov Bot commented May 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

codecov Bot commented Apr 13, 2026 •

edited

Loading

codecov Bot commented May 23, 2026 •

edited

Loading