Add file upload API and UI integration - #21
Merged
Merged
Conversation
📝 WalkthroughWalkthroughThis PR implements end-to-end chunked file upload support. The backend adds a Go ChangesChunked File Upload Feature
AGENTS.md Workflow Guidelines
Sequence Diagram(s)sequenceDiagram
participant Browser as Browser (useFileBrowserUploader)
participant Server as Server (HTTP handlers)
participant Manager as fileUploadManager
participant Disk as Filesystem
Browser->>Server: POST /api/file-tree/uploads (files metadata, destinationPath, chunkSize)
Server->>Manager: CreateSession(destPath, files)
Manager->>Disk: mkdir temp root, register in persistent registry
Manager-->>Server: sessionId, per-file serverFileIds, reserved target paths, total chunk counts
Server-->>Browser: CreateFileUploadResponse
loop For each file × chunk
Browser->>Server: PUT .../chunks/{index} (binary chunk blob)
Server->>Manager: UploadChunk(sessionId, fileId, chunkIndex, data)
Manager->>Disk: write chunk to .part file at offset
Manager-->>Server: received/total chunk counts
Server-->>Browser: FileUploadChunkResponse
end
par Client-side hashing
Browser->>Browser: IncrementalSha256.update(chunks)
Browser->>Browser: IncrementalSha256.finalize() → hex digest
end
Browser->>Server: POST .../complete (fileId, sha256)
Server->>Manager: CompleteFile(sessionId, fileId, sha256)
Manager->>Disk: hash temp file, compare SHA-256 vs provided
alt SHA-256 matches
Manager->>Disk: rename temp → final path (or copy-name if collision)
Manager-->>Server: finalPath, resolvedPath, serverSha256
Manager-->>Manager: release file reservation, remove session if all complete
else SHA-256 mismatch
Manager->>Disk: delete temp .part file
Manager-->>Server: HTTP 409 Conflict
Manager-->>Manager: release only this file's reservation (session remains)
end
Server-->>Browser: CompleteFileUploadResponse
opt Keep-alive
Browser->>Server: POST .../heartbeat
Server->>Manager: ExtendTTL(sessionId)
Manager-->>Server: FileUploadHeartbeatResponse (updated expiresAt)
Server-->>Browser: 200 OK
end
opt User cancellation
Browser->>Server: DELETE /api/file-tree/uploads/{upload_id}
Server->>Manager: CancelSession(sessionId)
Manager->>Disk: delete temp root, release all file reservations
Server-->>Browser: 204 No Content
end
opt Background TTL cleanup
Manager->>Manager: periodic cleanup ticker
Manager->>Manager: check LastSeenAt > TTL
Manager->>Manager: CancelSession (same as explicit cancel)
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Nitpick comments (3)
AGENTS.md (1)
136-136: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winConsider restructuring for conciseness.
The second bullet is longer and more complex than other guidelines in this document. Following the project's principle to "be concise and minimize prose," consider tightening it by separating concerns or using a numbered substeps format (similar to the "Goal-Driven Execution" section above).
Example restructure:
- Before implementing, check your branch: 1. On `master` or `main`? Pull latest, then create a new branch: `feat/`, `fix/`, or `docs/` with short meaningful name. 2. Already on a feature branch? No action needed.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@AGENTS.md` at line 136, The second bullet point under branch setup guidance is too verbose and violates the document's principle of conciseness. Restructure the bullet point that starts with "Before starting to implement anything please check the active branch" by breaking it into numbered substeps (1 and 2) that separate the concerns of checking branch status and pulling latest changes from the default branch versus the action to take when already on a feature branch. Simplify the language to match the brevity of other guidelines in the document while preserving all the essential information about branch naming conventions (feat/, fix/, docs/ prefixes) and keeping names short and meaningful.Source: Learnings
internal/server/file_upload_routes_test.go (1)
18-23: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReorder imports to match the repo’s Go import grouping rule.
The import block places internal imports before third-party imports. It should be grouped as: stdlib, third-party, internal.
Suggested diff
import ( "bytes" "crypto/sha256" "encoding/hex" "encoding/json" "net/http" "net/http/httptest" "os" "path/filepath" "strconv" "strings" "sync" "testing" "time" + "github.com/stretchr/testify/require" + "github.com/omnihance/omnihance-a3-agent/internal/config" "github.com/omnihance/omnihance-a3-agent/internal/constants" "github.com/omnihance/omnihance-a3-agent/internal/services" "github.com/omnihance/omnihance-a3-agent/internal/utils" - "github.com/stretchr/testify/require" )As per coding guidelines, "Group imports in Go files: Stdlib, Third-party, Internal (
github.com/omnihance/omnihance-a3-agent/...)."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/server/file_upload_routes_test.go` around lines 18 - 23, The imports in the file_upload_routes_test.go file are not properly ordered according to Go conventions. Reorder the imports block so that the third-party import (github.com/stretchr/testify/require) comes before the internal imports (github.com/omnihance/omnihance-a3-agent/internal/config, constants, services, and utils). Group them as: any stdlib imports first, then third-party imports, then internal imports, with blank lines separating each group.Source: Coding guidelines
cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-browser-uploader.tsx (1)
214-233: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUnify duplicated drop-upload logic to prevent drift.
The async
dataTransfer -> sources -> enqueueUpload -> toastflow is duplicated in two places. Extracting one helper keeps behavior aligned.Based on learnings, "Do NOT write redundant code" and "Write reusable functions and follow the DRY (Don't Repeat Yourself) principle".
Refactor sketch
+ const enqueueDroppedDataTransfer = useCallback( + async (dataTransfer: DataTransfer) => { + try { + const sources = await uploadSourcesFromDataTransfer(dataTransfer); + enqueueUpload(sources); + } catch (error) { + toast.error( + error instanceof Error ? error.message : 'Failed to read dropped files', + ); + } + }, + [enqueueUpload], + ); const handleDrop = useCallback( async (event: React.DragEvent<HTMLDivElement>) => { if (!canUpload) { return; } event.preventDefault(); event.stopPropagation(); setIsDragging(false); - - try { - const sources = await uploadSourcesFromDataTransfer(event.dataTransfer); - enqueueUpload(sources); - } catch (error) { - toast.error( - error instanceof Error - ? error.message - : 'Failed to read dropped files', - ); - } + await enqueueDroppedDataTransfer(event.dataTransfer); }, - [canUpload, enqueueUpload], + [canUpload, enqueueDroppedDataTransfer], );Also applies to: 338-353
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-browser-uploader.tsx` around lines 214 - 233, The dataTransfer processing and upload error handling logic in the handleDrop function is duplicated in another location (also around line 338-353). Extract the common pattern of calling uploadSourcesFromDataTransfer, then enqueueUpload, followed by the toast.error handling into a single reusable helper function. Then call this new helper from both duplicate locations to eliminate code duplication and ensure consistent behavior across both places where this upload flow occurs.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@AGENTS.md`:
- Line 135: Update the text on the line containing "Github CLI" to use the
correct product name capitalization "GitHub CLI" instead, ensuring the H is
capitalized in both occurrences of the product name on that line.
- Line 136: The grammar in the sentence uses the possessive form "its" when it
should use the contraction "it's" (meaning "it is"). In the AGENTS.md file,
replace both instances of "If its" with "If it's" - once before "master or main"
and once before "already in non default branch".
In `@cmd/omnihance-a3-agent/docs/openapi.yml`:
- Around line 5273-5278: The sha256 field in the openapi.yml file currently only
validates length (64 characters) but does not enforce hexadecimal format,
allowing non-hex 64-character strings that would fail backend validation. Add a
regex pattern constraint to the sha256 field definition in openapi.yml that
validates the string contains only lowercase hexadecimal characters (0-9 and
a-f). Then apply the same hexadecimal pattern validation to the sha256 field in
the CompleteFileUploadRequestSchema defined in
cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/lib/api.ts to ensure the
client-side schema matches the backend requirements.
In
`@cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-browser-uploader.tsx`:
- Around line 824-830: The deduplication logic in the file upload handler is
using case-insensitive comparison with toLowerCase() on lines 825 and 829, which
incorrectly treats distinct files with different cases (like Readme.txt and
README.txt) as duplicates on case-sensitive filesystems. Remove the
toLowerCase() calls when checking if a path exists in the seen Set and when
adding paths to the seen Set. Instead, store and compare the relativePath
directly in its original case, so that files with different cases are correctly
recognized as separate files during the deduplication process.
- Around line 501-513: The progress bar container lacks accessibility attributes
needed for screen readers to announce upload progress to assistive technology
users. Add the role attribute with value "progressbar" to the inner div element
(the one with dynamic width styling), and include ARIA value attributes
aria-valuenow set to the current progress percentage value, aria-valuemin set to
0, and aria-valuemax set to 100 to expose the upload progress semantics to
assistive technology. Consider also adding an aria-label attribute to describe
what task or file is being uploaded for better context.
In `@internal/server/file_upload_routes.go`:
- Around line 416-417: The `chunk_size` parameter has no upper bound validation,
which allows an attacker to declare arbitrarily large chunks and exhaust memory
when io.ReadAll buffers the entire chunk body. Add an upper bound validation
check on `chunk_size` before it is used to calculate `expectedSize` in the
io.LimitReader call. Implement this validation at all locations where chunk data
is read with io.ReadAll(io.LimitReader(body, expectedSize+1)) pattern to ensure
chunk_size cannot exceed a reasonable maximum threshold.
- Around line 95-107: The Start() method marks m.started as true before cleanup
succeeds, leaving the manager in an inconsistent started state if cleanup fails.
Move the assignment of m.started = true to after the successful completion of
m.cleanupRegisteredTempRoots() so the manager is only marked as started once
cleanup succeeds. Additionally, the Stop() method has a race condition where it
closes and immediately swaps the stopCh channel, which can cause the worker to
miss the stop signal if it re-enters the select statement after the swap.
Implement proper synchronization in Stop() to ensure the worker has fully
received and processed the stop signal before replacing the stopCh channel, such
as waiting for an acknowledgment from the worker or using a context with
cancellation instead of channel swapping.
- Around line 397-458: The UploadChunk method holds the mutex m.mu across
multiple I/O operations including reading the request body with io.ReadAll,
creating directories with m.fileEditor.MkdirAll, and writing chunks with
tempFile.WriteAt. Refactor the method to release the lock after validating the
upload session and file state checks (after the activeFileLocked call and before
io.ReadAll), perform all I/O operations without holding the lock, then
re-acquire the lock only to update the shared state like file.ReceivedChunks and
session timestamps before returning. This prevents blocking other sessions
during slow I/O operations.
---
Nitpick comments:
In `@AGENTS.md`:
- Line 136: The second bullet point under branch setup guidance is too verbose
and violates the document's principle of conciseness. Restructure the bullet
point that starts with "Before starting to implement anything please check the
active branch" by breaking it into numbered substeps (1 and 2) that separate the
concerns of checking branch status and pulling latest changes from the default
branch versus the action to take when already on a feature branch. Simplify the
language to match the brevity of other guidelines in the document while
preserving all the essential information about branch naming conventions (feat/,
fix/, docs/ prefixes) and keeping names short and meaningful.
In
`@cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-browser-uploader.tsx`:
- Around line 214-233: The dataTransfer processing and upload error handling
logic in the handleDrop function is duplicated in another location (also around
line 338-353). Extract the common pattern of calling
uploadSourcesFromDataTransfer, then enqueueUpload, followed by the toast.error
handling into a single reusable helper function. Then call this new helper from
both duplicate locations to eliminate code duplication and ensure consistent
behavior across both places where this upload flow occurs.
In `@internal/server/file_upload_routes_test.go`:
- Around line 18-23: The imports in the file_upload_routes_test.go file are not
properly ordered according to Go conventions. Reorder the imports block so that
the third-party import (github.com/stretchr/testify/require) comes before the
internal imports (github.com/omnihance/omnihance-a3-agent/internal/config,
constants, services, and utils). Group them as: any stdlib imports first, then
third-party imports, then internal imports, with blank lines separating each
group.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 052c6c1a-c1e3-4042-a25a-5622bbe7d0ef
📒 Files selected for processing (11)
AGENTS.mdREADME.mdcmd/omnihance-a3-agent/docs/openapi.ymlcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-browser-uploader.tsxcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-tree.tsxcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/lib/api.tsinternal/constants/constants.gointernal/server/file_system_routes.gointernal/server/file_upload_routes.gointernal/server/file_upload_routes_test.gointernal/server/server.go
Contributor
Author
|
@CodeRabbit review please |
|
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data/item-file-upload.tsx (1)
36-111: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoffConsider extracting the shared selection/validation logic.
ItemFileUpload,MapFileUpload, andMonsterFileUploadnow carry an almost identicalfile/validationErrorstate block,selectFileflow, and remove handler (differing only by label, icon, andmutationFn). A small shared hook (e.g.useGameClientFileUpload) would remove the triplicated logic.Based on learnings: "Write reusable functions and follow the DRY principle".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data/item-file-upload.tsx` around lines 36 - 111, Extract the duplicated file upload logic from ItemFileUpload, MapFileUpload, and MonsterFileUpload components into a custom hook called useGameClientFileUpload. Move the state declarations (file, isDragging, validationError, fileInputRef), the upload mutation setup, and all event handlers (handleDragOver, handleDragLeave, handleDrop, handleFileSelect) and the selectFile validation logic into this new hook. Have the hook accept parameters like fileLabel, maxFileUploadSizeBytes, and the mutationFn to handle the differences between the three components, then return the state variables and handlers as an object. Replace the duplicated code in each of the three components with a single call to this custom hook, reducing code repetition while maintaining the same functionality.Source: Learnings
internal/config/config.go (1)
191-198: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReplace magic numbers with a named constant.
Line 197 uses
1024 * 1024as a magic number for the MB-to-bytes conversion factor. As per coding guidelines, avoid using magic numbers in Go; use constants or named variables instead.♻️ Suggested refactor
Define a constant for the conversion factor:
+const bytesPerMegabyte = 1024 * 1024 + func (e *EnvVars) MaxFileUploadSizeBytes() int64 { maxFileUploadSizeMb := DefaultMaxFileUploadSizeMb if e != nil && e.MaxFileUploadSizeMb > 0 { maxFileUploadSizeMb = e.MaxFileUploadSizeMb } - return int64(maxFileUploadSizeMb) * 1024 * 1024 + return int64(maxFileUploadSizeMb) * bytesPerMegabyte }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/config/config.go` around lines 191 - 198, The MaxFileUploadSizeBytes() method uses the magic number 1024 * 1024 for converting megabytes to bytes. Define a named constant at the package level (such as BytesPerMegabyte or MbToBytes) with the value 1024 * 1024, and replace the hardcoded multiplication in the return statement of MaxFileUploadSizeBytes() with a reference to this constant to improve code readability and maintainability.Source: Coding guidelines
internal/server/upload_limits.go (2)
13-16: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReplace magic numbers with named constants.
Lines 14-15 use
1024as a magic number repeatedly. As per coding guidelines, avoid using magic numbers in Go; use constants or named variables instead.♻️ Suggested refactor
+const ( + bytesPerKilobyte = 1024 + bytesPerMegabyte = bytesPerKilobyte * 1024 +) + const ( - gameClientMultipartMemoryLimit = 32 * 1024 * 1024 - gameClientMultipartOverhead = 1024 * 1024 + gameClientMultipartMemoryLimit = 32 * bytesPerMegabyte + gameClientMultipartOverhead = bytesPerMegabyte )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/server/upload_limits.go` around lines 13 - 16, The constants gameClientMultipartMemoryLimit and gameClientMultipartOverhead use the magic number 1024 directly in their calculations. Create a new named constant to represent 1024 (one kilobyte) and replace all occurrences of the literal 1024 value with this constant reference in both constant definitions to follow Go coding guidelines against magic numbers.Source: Coding guidelines
35-56: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReplace magic numbers with named constants.
Lines 40, 42, 47, and 48 use
1024as a magic number. As per coding guidelines, avoid using magic numbers in Go; use constants or named variables instead. The samebytesPerKilobyteconstant suggested for the file constants can be reused here.♻️ Suggested refactor
func formatUploadSize(bytes int64) string { if bytes < 0 { bytes = 0 } - if bytes < 1024 { + if bytes < bytesPerKilobyte { return fmt.Sprintf("%d Bytes", bytes) } units := []string{"KB", "MB", "GB", "TB"} - divisor := int64(1024) + divisor := int64(bytesPerKilobyte) unitIndex := 0 - for bytes/divisor >= 1024 && unitIndex < len(units)-1 { - divisor *= 1024 + for bytes/divisor >= bytesPerKilobyte && unitIndex < len(units)-1 { + divisor *= bytesPerKilobyte unitIndex++ } value := float64(bytes) / float64(divisor) formatted := strconv.FormatFloat(value, 'f', 2, 64) formatted = strings.TrimRight(strings.TrimRight(formatted, "0"), ".") return formatted + " " + units[unitIndex] }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/server/upload_limits.go` around lines 35 - 56, Replace the magic number 1024 used throughout the formatUploadSize function with a named constant. Define a package-level constant named bytesPerKilobyte with the value 1024, then replace all four occurrences of the literal 1024 in the formatUploadSize function (in the initial bytes comparison, the divisor initialization, and the for loop condition checking bytes/divisor >= 1024 and divisor *= 1024) with references to this constant to improve code readability and maintainability.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@AGENTS.md`:
- Line 135: In the AGENTS.md file, change "GitHub related actions" to
"GitHub-related actions" by adding a hyphen between "GitHub" and "related". This
applies the correct compound modifier rule where "GitHub-related" acts as a
single descriptor for the noun "actions".
In `@internal/server/upload_limits.go`:
- Line 15: Remove the unused constant `gameClientMultipartOverhead` from the
upload_limits.go file. This constant is not referenced anywhere in the codebase
and should be deleted to eliminate dead code and improve code cleanliness.
---
Nitpick comments:
In
`@cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data/item-file-upload.tsx`:
- Around line 36-111: Extract the duplicated file upload logic from
ItemFileUpload, MapFileUpload, and MonsterFileUpload components into a custom
hook called useGameClientFileUpload. Move the state declarations (file,
isDragging, validationError, fileInputRef), the upload mutation setup, and all
event handlers (handleDragOver, handleDragLeave, handleDrop, handleFileSelect)
and the selectFile validation logic into this new hook. Have the hook accept
parameters like fileLabel, maxFileUploadSizeBytes, and the mutationFn to handle
the differences between the three components, then return the state variables
and handlers as an object. Replace the duplicated code in each of the three
components with a single call to this custom hook, reducing code repetition
while maintaining the same functionality.
In `@internal/config/config.go`:
- Around line 191-198: The MaxFileUploadSizeBytes() method uses the magic number
1024 * 1024 for converting megabytes to bytes. Define a named constant at the
package level (such as BytesPerMegabyte or MbToBytes) with the value 1024 *
1024, and replace the hardcoded multiplication in the return statement of
MaxFileUploadSizeBytes() with a reference to this constant to improve code
readability and maintainability.
In `@internal/server/upload_limits.go`:
- Around line 13-16: The constants gameClientMultipartMemoryLimit and
gameClientMultipartOverhead use the magic number 1024 directly in their
calculations. Create a new named constant to represent 1024 (one kilobyte) and
replace all occurrences of the literal 1024 value with this constant reference
in both constant definitions to follow Go coding guidelines against magic
numbers.
- Around line 35-56: Replace the magic number 1024 used throughout the
formatUploadSize function with a named constant. Define a package-level constant
named bytesPerKilobyte with the value 1024, then replace all four occurrences of
the literal 1024 in the formatUploadSize function (in the initial bytes
comparison, the divisor initialization, and the for loop condition checking
bytes/divisor >= 1024 and divisor *= 1024) with references to this constant to
improve code readability and maintainability.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 455a7a20-53c4-4a55-a8f1-e36701d84d0f
📒 Files selected for processing (23)
AGENTS.mdREADME.mdcmd/omnihance-a3-agent/docs/openapi.ymlcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data-page.tsxcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data/item-file-upload.tsxcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data/map-file-upload.tsxcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data/monster-file-upload.tsxcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data/upload-validation.tscmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-browser-uploader.tsxcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-tree.tsxcmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/lib/api.tscmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/lib/upload-validation.tsinternal/config/config.gointernal/config/config_test.gointernal/constants/constants.gointernal/server/file_upload_routes.gointernal/server/file_upload_routes_test.gointernal/server/game_client_data_routes.gointernal/server/game_client_data_routes_test.gointernal/server/server.gointernal/server/status_routes.gointernal/server/status_routes_test.gointernal/server/upload_limits.go
✅ Files skipped from review due to trivial changes (4)
- cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/client-data/upload-validation.ts
- internal/server/status_routes_test.go
- internal/constants/constants.go
- README.md
🚧 Files skipped from review as they are similar to previous changes (7)
- internal/server/server.go
- internal/server/file_upload_routes_test.go
- cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-tree.tsx
- cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/components/file-browser-uploader.tsx
- cmd/omnihance-a3-agent/omnihance-a3-agent-ui/src/lib/api.ts
- internal/server/file_upload_routes.go
- cmd/omnihance-a3-agent/docs/openapi.yml
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Testing
Summary by CodeRabbit