Repository navigation
Conversation
The instance-context middleware unconditionally called InstanceStore.load with whatever directory the client supplied, so requests that referenced a stale path (e.g. after the user moved the project folder) caused the server to bootstrap a phantom instance for a directory that doesn't exist on disk. Downstream calls on that instance then surfaced as 503 errors, and nothing pruned the stale entry from the client's cached project list. Add an fs.existsSafe guard at the middleware boundary: when the resolved directory does not exist, return 404 immediately so the client can drop the stale entry rather than retrying against a phantom instance. Fixes anomalyco#31888.
… variants
The OpenAI-compatible branch returned { high, max } but max is not part
of the OpenAI reasoning_effort enum. Spec-compliant upstreams (e.g.
hyper, Cloudflare AI Gateway) reject max with 400. The OpenRouter
branch already correctly uses xhigh. This aligns the OpenAI-compatible
branch to match.
Fixes anomalyco#34278
The --file flag hardcoded text/plain for all non-directory files, discarding the result of Filesystem.mimeType(). This caused image files (PNG, JPEG, etc.) to be passed to the LLM as garbled UTF-8 text instead of base64-encoded images. Now uses Filesystem.mimeType() to detect the correct MIME type based on file extension, falling back to application/octet-stream for unknown types. Fixes anomalyco#34318
Contributor
|
The following comment was made by an LLM, it may be inaccurate: POTENTIAL DUPLICATE FOUND:
This PR appears to be addressing the exact same issue as PR #34369 (the current PR). Both target fixing MIME type detection for You should check if PR #34319 has already been merged or is still open, and coordinate with the other PR to avoid duplicate work. |
Contributor
Author
|
Closing as duplicate of #34319. My PR includes 10 tests in \ est/cli/run/file-mime.test.ts\ — feel free to cherry-pick if useful. |
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
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.
Issue for this PR
Closes #34318
Type of change
What does this PR do?
When using the
--fileflag in local mode, all files were hardcoded astext/plainregardless of their actual type. Image files (PNG, JPEG, etc.) were passed to the LLM as garbled UTF-8 text instead of base64-encoded images.Root cause:
run.tsline 340 hardcodedmimeto"text/plain"for all non-directory files.Filesystem.mimeTypewas already available but the result was discarded.Fix: Changed line 340 to use
await Filesystem.mimeType(resolvedPath)which correctly detects MIME type based on file extension, falling back toapplication/octet-streamfor unknown types.How did you verify your code works?
Added
test/cli/run/file-mime.test.tswith 10 tests covering:image/pngimage/jpegtext/plainapplication/jsonapplication/octet-streamResult: 10 pass, 0 fail
Screenshots / recordings
N/A — logic fix, no UI change.
Checklist