feat(upload): send large assets in chunks so they clear a proxy body limit

[mickzijdel]

Issues Fixed

No existing issue. This is the fix for the problem behind #3302: I run Anthias behind Cloudflare, and uploading a large video fails. #3302 made the failure legible ("File too large - it exceeds the upload size limit of the server or a proxy in front of it"); this makes the upload work.

Description

The Add asset upload posts the whole file in one request, so a large video fails wherever a reverse proxy caps the request body. Cloudflare caps every non-Enterprise plan at 100 MB, a video of a few minutes clears that easily, and the operator cannot raise it. The bytes have to arrive in several requests instead.

Server. A ranged upload carries Content-Range. Each request stages its bytes into <assetdir>/.uploads/<id>.part and answers with JSON; only the request carrying the final byte falls through to create the asset, which is then a rename within one filesystem rather than a copy. Type detection, the display name and the extension all run before staging, so a file Anthias will refuse is refused on the first chunk rather than after the operator has waited out the whole upload. A request without Content-Range takes the original path untouched.

Browser. A file larger than the chunk size is sliced and sent sequentially, each slice re-wrapped as a Blob carrying the file's own type. That last part matters: a raw Blob from File.slice() reports application/octet-stream, and the server reads the browser's type to catch a file whose extension lies about it, such as a HEIC renamed to .jpg. Without the re-wrap the chunked path would skip normalisation and the asset would render blank on the player.

Progress is measured against the whole file rather than each request. A dropped connection or a 5xx resends the same chunk twice before giving up; a 4xx is the server's considered answer and is not resent. The chunk that commits is never resent once its body has gone out — see known limitation 2.

Chunk size. upload_chunk_size_mb in ~/.anthias/anthias.conf, then the ANTHIAS_UPLOAD_CHUNK_SIZE_MB environment variable, then 16. The config file comes first because it is the rung that survives an upgrade: upgrade_containers.sh regenerates docker-compose.yml from its template on every run, so a value set anywhere on the host is not persistence. The environment variable is how a balena device sets it, through a dashboard variable the supervisor injects. Clamped to [1, 24]: the ceiling keeps a chunk under FILE_UPLOAD_MAX_MEMORY_SIZE, where Django holds it in RAM rather than spooling it to the SD card, and below the floor a large video becomes thousands of sequential requests.

Parsed defensively, because this is set once and rarely looked at again. 16m previously raised ValueError while settings imported and the container never came up — on a headless device, with no shell to work out why. Read as a decimal and rounded down, since MB is decimal and an operator writing 8.5 to fit a 10 MB cap must not be handed 16, a value that cannot clear the cap they are trying to get under.

Guards that exist because the failure they prevent is silent. A chunk is refused if it would seek past what is actually held: the alternative is a hole that reads back as zeros and an asset that is corrupt at exactly the right size. The check runs against the open file descriptor rather than the path, so the cleanup sweep cannot delete the file in between. The final chunk truncates to the declared total, so a retry that shrank cannot leave the tail of a longer earlier attempt behind. Range digits are bounded, because int() raises above 4300 digits and a client-controlled header must not reach a 500. Free space is checked on every chunk against total_bytes - held, not only on the first: total_bytes is re-read from each request and never pinned, so a declared total that grows would otherwise never be measured against the disk.

Partials live under the same one-hour deadline as every other stray file in the asset dir, and are excluded from backups, which tar that directory recursively and would otherwise carry gigabytes of a file nobody finished sending.

Known limitations

Worth stating plainly rather than leaving to be discovered:

1. Chunks must arrive strictly sequentially, one in flight. What is tracked per upload is a byte count, not a set of received ranges, so a chunk starting past the end cannot be told apart from a resumed upload whose partial has gone. Both are treated as the latter: the partial is dropped and the operator asked to start over. Real resumability needs a received-ranges record and is not this change.
2. A commit whose response is lost leaves the operator unable to tell whether the asset was created. The server renames the partial into place and then answers, so a lost reply is indistinguishable from a lost commit. The commit is no longer resent once its body has gone out — on a dropped socket or a 5xx, since behind a proxy the lost-commit case usually arrives as a gateway 502 rather than a socket error. A body that never finished sending cannot have committed, so that case is still retried and reported as the ordinary transport failure it is. Both the client's message and the server's 409 point at the asset list before anything else, and the modal closes so the list is visible. Removing the ambiguity itself needs a commit marker I built, could not demonstrate, and removed rather than ship protection nobody can rely on. The single-shot path has the same ambiguity and now reports it the same way.
3. No fsync before the final rename, so power loss immediately after commit could leave the row pointing at unwritten data. Also true of the single-shot path today.

Testing

Verified through the real Add asset modal in Chromium, against a dev stack with the chunk size at 1 MB:

Source	4,195,538 bytes, sha256 10c63f2c9113aff7…
Stored asset	4,195,538 bytes, sha256 10c63f2c9113aff7…
Requests the server saw	5
Staging directory afterwards	empty
Server tracebacks	none

Byte-identical, through the browser, running the current bundle.

Unit tests cover the byte-exact multi-chunk round trip, ENOSPC while staging, the single-shot path staying unchanged when a stray upload id is present, rejection matrices for malformed ids and ranges (including the over-4300-digit total that used to 500), a chunk that lies about its length, a gap past the end of the partial, the final truncate, the free-space refusal on a growing total, and on the browser side the range arithmetic, the type re-wrap, the retry policy, the commit-is-never-resent rule and the error mapping.

2058 Python tests and 134 frontend tests pass, serially and under -n auto, with Redis unreachable — the no-Docker host recipe CLAUDE.md documents. ruff check, ruff format --check, mypy and tsc --noEmit are clean.

Not tested on hardware. My only Pi is in use, so the Raspberry Pi and x86 boxes on the checklist are genuinely unticked and nobody else has run this on a device either.

Since the last review

Six commits, in response to the review at 1cb0e31 and to problems found while re-auditing it.

The three findings from that review:

• HX-Redirect was dropped across the refactor. fix(auth): answer htmx callers with HX-Redirect, not a 302 #3306 adds a check on that header, for the expired-session case, in the exact handler this branch rewrote — so whichever of the two rebased second would silently lose it, and every file over the chunk size would be dropped from the batch with the operator never sent to sign in. Now carried and acted on in both places a response is classified, in the same shape and wording as fix(auth): answer htmx callers with HX-Redirect, not a 302 #3306, so the rebase resolves to the same thing twice rather than to silence.
• A rejection was assumed to come with a toast. fireToastFromHeader pushes nothing when there is no HX-Trigger, so an unrecognised 2xx dropped the file with no asset, no error and a completed progress bar. The test that pinned that behaviour asserted the toast list was empty, which is what it was describing: a toast that was not there.
• Free space was checked only at byte 0, so a declared total that grew was never measured. Now per chunk.

And four found by re-auditing:

• .tmp and .part files were served over HTTP. Three of the four transient shapes in the asset dir predate this branch — the REST API's <id>.tmp, the importer's .import-<hex>, and yt-dlp's <uuid>.<ext>.part — and all were fetchable on a LAN where the CIDR gate does not exclude clients.
• An asset could be stored under a name we delete. A crafted multipart part named clip.tmp with Content-Type: video/tmp was stored as <uuid>.tmp, which the hourly sweep removes, leaving a row pointing at nothing.
• The test suite wrote into the developer's real ~/anthias_assets and deleted its contents. Verified with a sentinel file, which did not survive one run.
• The chunk size could not be set on the docker-compose install at all, which is the install this feature exists for.

Two corrections to what this PR previously claimed. int() tolerates surrounding whitespace, so the trailing-space example I gave for the defensive parsing never crashed anything — 16m did, and that alone carries the argument. And "the server clamps to [1, 24]" oversold it: the clamp bounds what the server advertises, not what arrives.

Note on overlap

This touches the same upload code as #3306, so the two conflict. The HX-Redirect handling above is deliberately identical in shape and wording to #3306's, so whichever merges second resolves to the same thing twice. Happy to rebase at any point.

Checklist

• I have performed a self-review of my own code.
• New and existing unit tests pass locally and on CI with my changes.
• I have done an end-to-end test for Raspberry Pi devices.
• I have tested my changes for x86 devices.
• I added a documentation for the changes I have made (when necessary).

Tested end to end through a real browser against a dev stack, but not on hardware. The reverse-proxy FAQ entry that #3302 extended now documents the chunk size and where to set it.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 98.63014% with 2 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (master@ba28647). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
src/anthias_server/django_project/settings.py	94.87%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##             master    #3310   +/-   ##
=========================================
  Coverage          ?   90.47%           
=========================================
  Files             ?       85           
  Lines             ?    10075           
  Branches          ?     1126           
=========================================
  Hits              ?     9115           
  Misses            ?      707           
  Partials          ?      253           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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.

[vpetersson-bot]

Reviewed as untrusted input, with attention to the things a hostile upload path would hide: traversal through the client-supplied id, symlink swaps on the staged file, holes in the reassembled file, and unbounded disk use. I found nothing malicious, and the guards you built are the right ones. I ran the branch locally: ruff check, ruff format --check and bun test (118 pass) are clean, and 644 Python tests pass — with two exceptions, below.

The integrity argument holds

This is the part I most wanted to break, so it is worth saying that I could not. I worked through the overwrite cases by hand: a retried chunk whose start < st_size, a deliberately tiny first chunk followed by a large final one, and a final chunk landing exactly at st_size. In every case seek(start) + write leaves the file at end + 1, the per-chunk file_upload.size check pins that to the declared range, and the start_bytes > fstat(fd).st_size guard makes a gap unrepresentable. The committed file is always exactly total_bytes with every byte accounted for. truncate(total_bytes) on the final chunk closes the shrinking-retry case. Measuring the open descriptor rather than the path, for the reason you give, is the right call.

The rest of the perimeter checks out too:

• _UPLOAD_ID_RE.fullmatch on 32 lowercase hex closes traversal; O_NOFOLLOW closes the symlink swap; the 19-digit bound really does keep int() off its 4300-digit ValueError.
• The orphan sweep in cleanup() uses os.scandir + is_file(), so .uploads is skipped rather than swept, and the existing *.tmp find cannot match *.part. The new .part sweep is the only thing that touches partials, and each chunk refreshes the mtime, so a slow upload is safe.
• tarfile.add returns before recursing when the filter yields None, so _skip_staged_uploads genuinely prunes the subtree rather than just omitting the directory entry.

Findings

Two I would fix before merge and two smaller ones, all inline. Summarised:

1. Two of the new tests fail without Redis — reproduced locally, and it breaks the no-Redis host recipe CLAUDE.md documents.
2. The rationale for the chunk size is inverted. /tmp is not RAM in these containers, so staying under FILE_UPLOAD_MAX_MEMORY_SIZE forces each chunk into memory rather than keeping it out. The 16 MB number is still defensible; the reason given for it is not.
3. int(getenv(...)) on a device variable can stop the server from starting.
4. Known limitation 2 is described as the wrong failure. What the operator actually sees is an error, not a silent success — which changes how it should be documented.

On the overlap with #3306: no view from me on merge order, but the conflict is in assets_upload and home.ts, both of which this PR restructures substantially, so whichever lands second is a real rebase rather than a mechanical one.

[vpetersson-bot]

These two tests need Redis, and the sibling tests in this file deliberately do not.

Reproduced on a host with no Redis running:

FAILED tests/test_template_views.py::test_assets_upload_chunked_round_trip_is_byte_exact
FAILED tests/test_template_views.py::test_assets_upload_final_chunk_truncates_a_longer_earlier_attempt
RuntimeError: Retry limit exceeded while trying to reconnect to the Celery result store backend.

The cause is the .mp4 payload: a video upload sets is_processing and the view dispatches normalize_video_asset.delay for real, which reaches for the Celery result backend. Every other video-upload test in this file wraps that in mock.patch('anthias_server.celery_tasks.normalize_video_asset.delay') — these two do not.

This matters beyond a local inconvenience: CLAUDE.md documents uv run pytest -m "not integration" on the host as a no-Docker, no-Redis run, and the root conftest.py force-mocks lib.utils.connect_to_redis but not Celery's broker. So the suite as documented now has two hard failures, while CI (which has Redis) stays green — the combination that leaves this kind of thing sitting for months.

Fix is either mock the delay like the neighbours do, or make the payload an image, since neither test is about the video pipeline. test_assets_upload_final_chunk_truncates_a_longer_earlier_attempt has the same problem at line 2853.

[vpetersson-bot]

/tmp is not RAM here, so this reasoning runs the wrong way.

The premise is true of Raspberry Pi OS on the host, but this code runs in a container, and I checked all four compose files — docker-compose.yml.tmpl, docker-compose.balena.yml.tmpl, docker-compose.dev.yml, docker-compose.test.yml. None mounts a tmpfs at /tmp for anthias-server (the only tmpfs-adjacent setting anywhere is shm_size on the viewer), and FILE_UPLOAD_TEMP_DIR is unset. So /tmp inside the container is the writable overlay layer, i.e. the SD card.

That inverts the trade-off: staying under FILE_UPLOAD_MAX_MEMORY_SIZE is what puts a chunk fully in RAM, via MemoryFileUploadHandler. Exceeding it is what would have spooled it to disk. So the chunk ceiling is not protecting the 512 MB board's memory — it is spending it, 16 MB per concurrent chunk request.

Worth being clear that this is a comment-and-rationale problem, not necessarily a code one. 16 MB resident per in-flight upload is a defensible number, and it is better than the status quo, where a 100 MB single-shot upload spooled the whole 100 MB somewhere. But the same wrong premise drives MAX_CHUNK_MB = 24 in chunking.ts, and a future maintainer reasoning from it will reach for the opposite of what they intend. Either correct both comments to say "buffered in RAM, so keep it small", or point FILE_UPLOAD_TEMP_DIR at the asset volume and size chunks to what proxies actually need.

[vpetersson-bot]

A typo in this device variable stops the server from starting.

This is the only int(getenv(...)) in settings.py, and it is unguarded: ANTHIAS_UPLOAD_CHUNK_SIZE_MB=16m (or 16 with a trailing space that a Balena variable field will happily keep) raises ValueError during settings import, and the container never comes up. On a headless device set through the Balena dashboard, the operator has no shell to work out why, and the value they typed is the sort of thing people set once and never look at again.

Two smaller things while you are here:

• Values above 24 are silently ignored, because the cap lives only in chunkSizeFromMeta. An operator who reads the docstring and sets 32 to match their proxy gets 24 with no indication.
• There is no lower bound either. 0.5 yields ~512 KB chunks, so a 2 GB video becomes ~4000 sequential requests, each with its own round trip and multipart parse.

Parsing defensively with a fallback to 16 and a warning, plus clamping to something like [1, 24] server-side, makes the client cap a second line of defence instead of the only one.

[vpetersson-bot]

This is the path that produces known limitation 2, and it does not fail the way the PR body describes.

The body says a commit that times out after succeeding "can produce a duplicate asset if the client retries". The mechanism is a bit different, and the difference matters for how it should be documented.

sendUpload resolves status: 0 on a dropped connection, and uploadOne treats status === 0 as retryable — including for the final chunk. So when the commit succeeds but the response is lost, the retry arrives after os.replace has already moved the partial away. os.open with O_CREAT recreates it empty, start_bytes > st_size fires here, and the client gets a 409.

What the operator sees is therefore "This upload expired. Please try uploading it again." for an upload that completed and created the asset. They do what the message says, and that is where the duplicate comes from — a second full upload, not a retried commit.

I would not ask you to build the marker you already removed. But the limitation is worth restating in these terms, because "may produce a duplicate" reads as a silent, harmless outcome, whereas the actual outcome is an error message that actively instructs the operator into the duplicate. If the message is all that is on offer, it could at least say the upload may have gone through and to check the list before retrying.

[vpetersson-bot]

Low severity, but worth a thought while the location is still cheap to change: .uploads sits inside anthias_assets, which is served over HTTP. views_files.anthias_assets resolves /anthias_assets/.uploads/<id>.part to a real path under ANTHIAS_ASSETS_ROOT, so the startswith guard passes and the file is served. That view's own comment says the DOCKER_BRIDGE_CIDR gate "does not actually exclude LAN clients" in the default no-SSL install, since REMOTE_ADDR is the bridge gateway.

In practice the 32-hex id is unguessable and there is no directory listing (IsADirectoryError becomes a 404), so this is not something I would hold the PR for. But partial uploads are the one thing in that tree that was never meant to be fetchable, and staging under ~/.anthias/ instead would take them off the HTTP surface entirely. Both live under the same mount, so the same-filesystem rename that makes the commit cheap still holds — it would cost the backup filter and the sweep path, and nothing else.

[vpetersson-bot]

Nit: this branch and the return at the end of the function are both unreachable. res is assigned on every iteration of the inner retry loop, which always runs at least once, so it is never null by the time you get here; and needsChunking guarantees at least two chunks, the last of which returns via interpretFinalResponse.

Harmless, but the trailing { kind: 'network' } reads like a real fallback for "ran out of chunks without committing", which cannot happen.

[vpetersson-bot]

Besides the Redis dependency noted above, this test pins down a contract worth a second look: chunk one declares /40 and chunk two declares /10 for the same upload id, and the server accepts the change. total_bytes is never compared against what earlier chunks declared.

The offset and size guards mean nothing corrupt comes out of it — the committed file is exactly the new total, with every byte written — so this is not a bug. But no real client shrinks the total mid-upload, and encoding it in a test makes "the declared size may change between chunks" a supported behaviour that someone later has to preserve. If the intent is just to prove truncate works, driving it with a consistent total and a genuinely longer earlier attempt under the same total would test the same line without fixing the looser contract in place.

[vpetersson-bot]

Reviewed at 1cb0e31. The staging protocol and its integrity guards I could not break, and the line-by-line audit from the earlier round still holds at this head. My findings are all at the edges: two in how the browser classifies a response, one in a guard that reads stronger than it is.

Verification

Ran on the host with no Docker and no Redis, the recipe CLAUDE.md documents:

uv run pytest -m "not integration"	2047 passed, 63 deselected
Same, -n auto	2047 passed
bun test	128 passed
ruff check / ruff format --check	clean
mypy	no errors in any file this PR touches

Both regressions from the last round are genuinely fixed: the two round-trip tests mock normalize_video_asset.delay now, so the documented no-Redis host run is green, and the -n auto run is clean, which is what the shared-asset-dir fixture was about.

1. HX-Redirect is dropped on the chunked path, and #3306 is where that starts to matter

This is the one I would fix before merging, because it is a rebase hazard rather than a visible bug today.

#3306 — which you already note conflicts with this — adds an HX-Redirect check to sendUpload's load handler for exactly the expired-session case: without it a 302 is followed transparently, the login page arrives under a 200, and that reads as a stored file. It resolves { status: 'error', failure: { kind: 'auth' } } straight out of that handler.

This PR refactors that handler so it no longer produces an UploadResult — it produces a RawUploadResponse carrying status / text / trigger / bodySent, and the classification moves out to interpretFinalResponse and the chunk loop. HX-Redirect is not among the fields carried across. So whichever of the two rebases second, resolving the conflict mechanically leaves the chunk loop unable to see the header at all:

Anthias/src/anthias_server/app/static/src/home.ts

Lines 708 to 711 in 1cb0e31

	if (jsonStringField(res.text, 'upload_id') === undefined) {
	fireToastFromHeader(res.trigger)
	return { status: 'rejected' }
	}

A non-final chunk answering 204 + HX-Redirect: /login/ has no upload_id in its empty body, so it becomes { status: 'rejected' }. The file is dropped from the batch, the loop moves on to the next file and drops that one too, and the operator is never sent to sign in. #3306's fix would silently stop applying to every file larger than the chunk size — which is precisely the set of files this PR exists to serve.

The fix is small: add redirect: string | null to RawUploadResponse, populate it in sendUpload, and act on it in both the chunk loop and interpretFinalResponse. Worth doing on this branch now rather than leaving it to conflict resolution, where it will not surface as a conflict.

2. The chunk loop assumes a rejection always comes with a toast

Same code, independent of #3306:

if (jsonStringField(res.text, 'upload_id') === undefined) {
  fireToastFromHeader(res.trigger)
  return { status: 'rejected' }
}

fireToastFromHeader returns null and pushes nothing when there is no HX-Trigger. So any 2xx that is not the acknowledgement and carries no toast — a login page, a captive-portal interstitial, a proxy's own 200 — drops the file with zero user-visible feedback: no asset appears, no error, and the progress bar completes normally.

interpretFinalResponse already draws this distinction:

return { status: kind === 'error' ? 'rejected' : 'ok' }

The chunk loop does not. The new test a non-JSON 200 is a rejection, not a transport failure pins the silent behaviour — its stub is { status: 200 } with no trigger, and it asserts toasts is empty, so the comment's "the server's own toast stands alone" is describing a toast that is not there.

Branching on the returned kind the way the final-response path does is a one-liner and closes the tail of finding 1 too.

Worth noting this is also the only thing standing between the operator and a silent bad outcome if a proxy ever strips Content-Range from the request: the server then takes the single-shot path — as designed, and as test_assets_upload_single_shot_ignores_a_stray_upload_id asserts — and stores the first chunk as a complete asset. A truncated video with an error toast is recoverable; a truncated video in silence is not.

3. The free-space guard only runs on the chunk starting at byte 0

_stage_upload_chunk gates the shutil.disk_usage check on start_bytes == 0, and total_bytes is re-read from each request without being pinned. A client whose declared total grows after the first chunk is never checked against the disk at all.

Confirmed rather than reasoned — I drove the real view with disk_usage mocked to 100 bytes free:

chunk 0:  bytes 0-9/50      ->  200   (50 < 100 free, passes)
chunk 1:  bytes 10-299/300  ->  200   (no check runs; asset committed at 300 bytes)

control:  bytes 0-9/300     ->  507   (declared up front, correctly refused)

Not a security issue — an authenticated operator can fill the card with single-shot uploads regardless — but the code and the PR body both read as though the refusal is a property of the upload, and it is a property of the first request only. Running the check on every chunk against total_bytes - os.fstat(f.fileno()).st_size is stateless, costs one statvfs per chunk, and needs no received-ranges record.

This is also the concrete consequence of the "the declared total may change between chunks" contract raised last round. That was answered by tightening the test; the looseness in the code is what produces the above. I would not ask you to pin the total — that needs state this design deliberately avoids — but the per-chunk disk check gets most of the value for free.

Smaller things

• docker-compose.dev.yml does not pass ANTHIAS_UPLOAD_CHUNK_SIZE_MB through, so reproducing the fix in the dev stack — the setup you tested against — needs a file edit. One line, and it makes the FAQ recipe exercisable by the next person.
• .uploads is created but never removed, so an install that once had a chunked upload keeps an empty directory forever. Cosmetic.

On the rest

I spent most of my time trying to make the reassembly produce a wrong file and could not. The fstat on the open descriptor rather than the path, O_NOFOLLOW on a client-named path, the 19-digit bound keeping int() off its ValueError, the final truncate, and os.replace within one directory are each the right call. The EXDEV argument for why .uploads cannot live under ~/.anthias is correct — separate bind mounts make the commit a copy, and on this hardware that is the wrong trade.

Two judgement calls worth recording as correct rather than merely accepted. The 24 MB ceiling is right for the stated reason: FILE_UPLOAD_MAX_MEMORY_SIZE is 26_214_400, and a 24 MB chunk plus multipart overhead lands under it with about 1 MB of headroom, so MemoryFileUploadHandler keeps it in RAM. And rounding a fractional size down is right — this knob only ever exists to get under someone's cap, so every fallback has to go that way.

The known limitations are stated honestly, and limitation 2 in particular now describes what the operator actually sees rather than a vague "may produce a duplicate". Not resending the commit once its body has gone out — including on a 5xx, since behind a proxy that is the common shape — is the right resolution given that removing the ambiguity needs a marker you could not demonstrate.

Recommendation: finding 1 before merge, since it will not announce itself during the rebase with #3306. Findings 2 and 3 are small enough to fold into the same pass. Nothing here touches the staging protocol itself.

One caveat on scope: I reviewed against a dev checkout and CI, not hardware — your own checklist leaves the Pi and x86 boxes unticked, so the end-to-end device path is still unverified by anyone.

[sonarqubecloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud