- require command-line evidence for owned service processes
- discard unprovable stale records instead of blocking startup
- identify and stop our own unhealthy conflict; serialize stop with start
- reject IPv6 loopback endpoints
- rotate oversized logs and fix tailing multibyte cuts
- add tests for env writes, client failures and real spawner
- wire the package mirror into installs
- wait for service exit, escalate to SIGKILL, keep the record on failure
- fail closed on ownership and clear dead service records
- clear the start lock on failure and reject overlapping starts
- bound probes, make config writes atomic, scope auth tokens
- fix docs and add regression tests
dispose() on the manager stops running installs, but nothing tied that to
the plugin's own lifetime: a change to the registration could have left
pip running after the plugin unloads. Mount the plugin, replace the
provided manager's dispose with a counter, run the envLifetime cleanup and
assert it is called once.
The memory settings card carried its own draft state machine: a Draft
object, a parser that re-validated every field, a hand-written diff into
path operations, and its own revision fence. DSH ships exactly that as
SettingsFormModel, exported by the primitives package this plugin already
depends on and injects since 0.1.7-rc.2.
The card now builds the model once, reads shell()/field() while rendering
and hands every edit to actions(), so what is left is the controls plus
one field-spec table in settings-specs.ts. The revision fence, the
dirty/invalid/saving/failed states, keeping drafts after a refused save,
and clearing only the fields the user layer carries all come from the
model.
The one visible change: reset now stages clears for the fields the user
layer actually overrides, which is what that control always meant.
Tests: settings-specs.test.mjs covers every spec on its own, and the card
test runs DSH's real SettingsFormModel (evaluated from the installed
primitives bundle, which cannot be imported in Node because it loads CSS
modules and icons). The packaged-plugin check exercises that against all
six supported DSH releases.
The interpreter helpers mixed simulated-platform knowledge with the host's
node:path, so Windows fixtures only resolved on Windows: on macOS and
Linux condaRootFromPath, pathContains, pythonPrefix, classifyOrigin,
remeCliPath and the pip path check all fell back to POSIX semantics and
nine tests failed.
Paths now carry their flavor: pathOf() picks win32 or posix from the value
itself, and the functions that already know the simulated platform use it
explicitly. Behaviour on Windows is unchanged; the same fixtures now
resolve identically on every host, which the new tests assert for both
flavors.
The two READMEs keep a short introduction to the Environment tab and link
to docs/environment.md / docs/environment_ZH.md, which now carry the
setup and troubleshooting detail: Python and conda discovery plus the
recommendation rule, dependency installation, .env validation and
clearing, connection testing, the detached service lifetime, platform
support and the failure modes of each step.
The version lists include 0.2.2-alpha.2 and note that current DSH needs
Node 24.9 or newer. The package now ships docs/ as well, so the guide
travels with the published plugin.
Local now means the DSH Host everywhere. The tab no longer fetches the
service URL from the browser: the hero reads the same Host probe the
service card uses, and a remote endpoint is probed through a new
remeEnv/health method, so a browser on another machine cannot disagree
with the Host. The wire namespace, method parameter convention and
service keys are unchanged.
Process lifetimes are explicit and documented in the manager. Python
probes and reme-ai checks stay bounded one-shot commands. pip installs
live in the manager's registry, keep the interpreter locked between a
cancel request and the actual exit, and are stopped by dispose() when
the plugin unloads. The ReMe service stays detached on purpose: it must
outlive DSH, so it is not handed to DSH's subprocess provider, which
kills its children on Host exit; it is stopped only through the
ownership-checked adapter in service.ts.
That adapter now verifies identity before reporting or stopping a
service: the recorded endpoint must match, the pid must be alive, and
its image must still be Python or reme, which protects against pid
reuse. A launch is recorded only after the OS acknowledged the spawn,
and a spawn failure returns an error instead of an unhandled event.
Starts are serialized and re-check the phase inside the lock, so two
requests cannot spawn two services. Health answers are validated, so a
generic HTTP server answering 200 with '{}' is no longer reported as a
running ReMe service, and authToken now rides the Authorization header
of both the client requests and the Host probe.
.env merging rewrites every occurrence of a key (parsing keeps the last
one), keeps the file's line ending, and validates the merged file rather
than just the submitted values.
The tab was one 2,213-line component with 27 state hooks. It is now one
module per step, and each step owns the asynchronous state it shows:
client/tab.tsx layout, hero, the settings reads
client/python.tsx usePython + the interpreter section
client/dependency.tsx useDependency + the reme-ai section
client/workspace.tsx useWorkspace + the .env section
client/service.tsx useService/useHealth + the service section
client/presentation shared badges, tags and field frames
client/rpc.ts the remeEnv calls and their response guards
client/locales.ts the tab's copy
client/styles.ts the tab's CSS
The .env controls now come from one field table, and the stylesheet split
keeps the tab's CSS next to the tab.
State is keyed where the review asked for it: install progress carries the
job id it polls and cancels, workspace drafts and in-flight saves carry the
workspace they were typed for, and a check result only shows for the
interpreter it belongs to. Drafts also distinguish untouched fields from
explicit clears, so emptying a non-secret field now clears it on disk. The
memory settings draft parser no longer carries the environment fields
through, since saving only writes this page's FIELDS list.
Move the Host modules out of src/pyenv and the tab out of src/client so
the feature has one boundary:
src/environment/types.ts browser-safe RPC contract
src/environment/host/*.ts detection, install, service, workspace
src/environment/client/* the Environment tab
src/environment/host/gateway remeEnv RPC surface
src/environment/host/manager the operations the gateway exposes
The cross-boundary shapes (detection, reme-ai check, install job, .env
summary, service state) now live in one browser-safe module instead of
being pulled from Host modules that import node built-ins; Host-only
shapes stay beside the code that owns them. src/index.ts registers the
gateway and manager, src/client/index.tsx mounts the tab. The wire
namespace, method names and service keys are unchanged.
Add the current DSH release to the peer ranges and to the package
compatibility matrix (cordis 4.0.6-alpha.1, loader 1.0.7-alpha.1,
schemastery 3.18.6-alpha.1), which needs Node 24.9 or newer.
The packaged-plugin check now launches the npm CLI through node using
the npm_execpath npm exports, so it also runs on Windows where npm is
npm.cmd and execFile cannot start it.
The tab renders a hero from /health_check on mount. The test asserted the ready state, which only held while a local ReMe service was running, so it failed on CI runners. Replace global fetch with a canned health response for the duration of each test.
The environment tab rendered as one flat column: five identical headings,
every detected interpreter in one long list, and the whole .env form
always expanded. That reads like prose and grows without bound on
machines with dozens of conda environments.
- Lead with a status hero (endpoint, service/Python/ReMe chips, retest and
rescan) so the current state is readable at a glance.
- Turn the four remaining groups into numbered cards with a status pill in
the header, so setup order and per-step state are obvious.
- Show only the interpreter in use, then reveal the rest on demand:
search box, six rows per page, and a show-all toggle.
- Collapse the .env editor behind a summary line (path + model).
- Explain the "recommended" marker through a tooltip; the flag now also
distinguishes an outdated reme-ai (amber) from a current one.
- Expose versionOk on the detection probe so the client can tone the tag
without importing host-only modules.
- Add a react-test-renderer suite covering the hero, card count, collapsed
list, pagination and interpreter selection.
TypertRemoteService registers itself under the constructor key, so
`super(ctx, remeEnv)` collided with the already-provided `remeEnv`
manager: the gateway plugin failed activation (its async rejection was
logged only), leaving every /api/remeEnv/* call with HTTP 404.
Register the service as `remeEnvGateway` and keep the wire namespace
`remeEnv`, which is what the client calls. Add a real-cordis regression
test that mounts the gateway inside the same isolated realm and asserts
the binding, the namespace, and the SRC-parsed `input` parameter.
Also show the interpreter hint on detection failure so an empty list
never leaves the tab without guidance.
Describe the five Environment sections, the .env and EMBEDDING_API_KEY
contracts, local service control semantics, and the optional authToken
field in both READMEs.
- service status combines a direct /health_check probe with port probing:
running (managed or foreign), port conflict, or stopped
- start composes `reme start` with an absolute workspace_dir and
service.host/port, runs it detached inside the workspace (so ReMe's
.env discovery works), injects UTF-8 and NO_PROXY, disables the rich
logo, and only passes jobs.dream_cron.enabled=false on reme >= 0.4.1
- the plugin records the PID and launch arguments in service.json, so
stop can tree-kill the managed process; foreign instances are shown
but not touched
- serviceLog exposes the workspace log tail for start-failure diagnosis
- optional autoStart setting starts a stopped local service when DSH
boots, using the selected interpreter (or the detected suggestion)
Real-machine check: started ReMe 0.4.0.9 on port 2334 in a temp
workspace, observed running/managed with the recorded PID, then
stopped it and confirmed the port was released.
- read the workspace .env as a masked projection: non-secret values are
editable, API keys return only •••• plus their last four characters
- merge edits into the existing file, preserving comments, ordering and
unknown variables; validate the effective file so an untouched real
key still satisfies the LLM requirement
- require a non-empty EMBEDDING_API_KEY (EMPTY placeholder fills in on
first save), because ReMe 0.4.0.x aborts startup without one
- test the configured LLM endpoint from inside the workspace with the
selected interpreter, classifying 401/404/network failures
- add the remeWorkspaceDir setting (empty means ~/.reme) consumed by
the .env editor and later service management
Real-machine check: masked read leaks no secret, temp-workspace write
is idempotent and rejects an empty embedding key, and the LLM probe
against the local ~/.reme/.env returned HTTP 200.
- check reme-ai version, the [core] AgentScope import and the reme CLI
for the selected interpreter; an outdated install is flagged instead
of treated as ready
- one-click pip install of reme-ai[core] as a Host job: per-job log file,
2s log-tail polling, cancel, and running-job restore after a page
reload; the optional mirror overrides pip only for that run
- interpreter detection now probes reme-ai per environment, so the
suggestion prefers a named conda env with a usable reme (an outdated
reme no longer outranks a ready environment)
- fix: DSH exposes these Remote methods in SRC mode, which parses the
method source; every method takes one plain `input` identifier
parameter (no defaults or destructuring) and the client sends
`{ args: { input } }`
Adds a read-only Environment tab to the ReMe Memory settings card so
users can see why the ReMe service is unreachable before touching a
terminal:
- discover local Python interpreters via the PEP 514 registry, py
launcher, PATH and conda (base + named envs), then verify every
candidate by actually running it
- classify origins (conda base/env, python.org, Microsoft Store, venv,
system PATH), drop Store alias stubs, and suggest a preferred
interpreter (Python >= 3.11, named conda envs first)
- expose detection to the browser through a new remeEnv host gateway
(TypertRemoteService) and render it with a connection health check
- config gains optional authToken and pythonPath fields with unchanged
defaults; existing memory settings keep their behavior
Parsing is fixture-tested against real tool output on Windows (GBK
codepages, localized reg labels, missing py launcher) and Linux.
A per-item context-length rejection survives the per-item split: the item is resent unchanged and the provider keeps rejecting it, so the chunk never gets a vector and a scoped reindex can never finalize. Re-prepare that single item under a smaller character budget and retry it once, bounded by max_retries.
Only the request shrinks. The chunk keeps its full source text, the vector space is unchanged, and the shortening is logged so the reduced coverage is visible.
Shortening needs an attempt left to send. On the final attempt a shorter request cannot be delivered, so that branch now falls through to the existing input-dependent handling: the rejection stays specific to its item instead of being recorded as a terminal batch failure that drops the healthy items after it. The retry lives inside the input-dependent branch, so the same error is classified once, and the single-use budget helper is inlined.
Follow-up to the merged per-item isolation change (#579), rebased onto the retry-result refactor (#656).
* fix(embedding): keep one bad item from dropping its whole batch
A provider-side request error rejects an entire batch, so a single over-limit
item used to cost the vectors of every item beside it. QwenPaw #8040 shows two
poison chunks turning into exactly twenty lost vectors, while the backfill loop
still reported full success.
Retry a rejected multi-item request one item at a time so only the item that
actually fails is left without a vector. Single-item requests keep their
previous behaviour, and provider-level failures (429 / quota) keep using the
existing retry paths instead of being split.
Also make the backfill loop report what it actually filled, and name the failing
chunk ids in the final reindex error. `processed` counts attempts, so it claimed
success after a partial loss.
* fix(embedding): stop quota failures and transient item errors from multiplying
Review follow-up on the two P2 findings in #579:
* quota exhaustion no longer falls into the per-item split. The store now gives
up explicitly when the provider reports insufficient_quota, including after
the opt-in quota retries are spent, because no single item is to blame and
splitting only multiplied the rejected requests (3 items -> 4 requests).
* the per-item fallback goes back through `_call_with_retry`, so a 429,
connection error or timeout on an isolated item keeps the existing backoff
and retry policy instead of silently dropping that item's vector. A one-item
request still cannot split again.
Regression tests cover both findings: a quota failure stays a single request
with the default policy and with exhausted quota retries, and a transient
failure on one item of a split batch still ends with every healthy sibling
embedded.
python -m pytest tests/unit/test_local_embedding_store.py tests/unit/test_file_store_consistency.py -q
-> 83 passed, 41 skipped
* style(test): hoist the sleeps collector out of the transient-failure loop
CI / Python quality failed on d5dc9b2: the pylint hook reported
tests/unit/test_local_embedding_store.py:935:16:
W0640: Cell variable sleeps defined in loop (cell-var-from-loop)
`fake_sleep` closes over `sleeps` while the loop rebinds it on every
iteration. The collector is now created once before the loop and cleared
at the top of each iteration, which keeps the per-iteration assertion
(`assert sleeps == [1.0]`) exactly as strict and removes the loop-scoped
rebinding.
Verification (repo hook arguments):
pylint -> Your code has been rated at 10.00/10, exit 0
black --check --line-length=120 --target-version=py311 -> clean
flake8 --extend-ignore=E203 --max-line-length=120 -> clean
* fix(embedding): keep provider-wide failures out of the per-item split
Review follow-up on the P2 raised against 4d8a3c5.
`_call_with_retry` sent every unrecognized exception to `_embed_individually`
whenever the request had more than one item. Only rate limiting and
`insufficient_quota` were excluded, so a 401, a 403 or a 5xx still split a
ten-item request into ten extra single-item requests, none of which can
succeed: credentials, permissions and server outages are properties of the
endpoint, not of any individual input.
The split path is now gated on a dedicated classifier,
`_is_provider_wide_failure()`, which recognizes 401/403 and 5xx by status
code (with the OpenAI SDK class names as a fallback for exceptions that do
not expose one). Transient server errors keep their retry policy through the
existing backoff; the remaining provider-wide failures stop the loop and
report unhealthy, like the quota branch. Input-dependent rejections such as
the per-item context-length limit are unchanged and still isolate one item
at a time.
Regression coverage: test_provider_wide_credentials_errors_are_not_split_into_per_item_requests
(401/403 -> a single request of size 10) and
test_provider_wide_server_errors_are_retried_without_splitting
(500 -> batch sizes [10, 10, 10] with sleeps [1.0, 2.0]). The existing
context-length, quota, 429 and per-item transient-retry tests are retained.
Local verification, using the repo's own hook arguments:
pylint -> Your code has been rated at 10.00/10, exit 0
black -> 2 files would be left unchanged
flake8 -> clean
Classifier discriminator check (old vs new split decision, extracted from the
production file and executed):
400 context-length -> SPLIT / SPLIT
401, 403, 500, 504 -> SPLIT / NO-SPLIT
429 and insufficient_quota keep their own earlier branches.
* fix(embedding): retry SDK transport failures instead of splitting the batch
Third review follow-up on #579.
`_call_with_retry` only caught the built-in `TimeoutError`, `ConnectionError`
and `OSError`. `openai.APIConnectionError` and `openai.APITimeoutError` do not
inherit from any of them (they go APIError -> OpenAIError -> Exception), so
they reached the generic handler: `_is_provider_wide_failure()` did not
recognize them either, and a multi-item request fanned out into per-item
requests that failed for exactly the same reason. The same gap meant a
single-item request got no ReMe-level retry at all after a transport failure.
Transport failures are now recognized by a dedicated classifier,
`_is_transient_transport_failure()`, covering the built-in socket errors as
well as the SDK/httpx exception types (matched across the MRO, so subclasses
such as `APITimeoutError` are included) without importing the provider SDK.
They retry the original request with the existing backoff and never split; the
retry budget is unchanged.
Regression coverage:
- test_sdk_transport_errors_are_retried_without_splitting
APIConnectionError / APITimeoutError -> batch sizes [10, 10, 10], sleeps
[1.0, 2.0], then failure with no single-item requests.
- test_sdk_transport_error_recovers_without_losing_the_batch
one APITimeoutError then success -> [[1.0, 0.0]] * 10, batch sizes [10, 10].
- test_isolated_item_retries_an_sdk_transport_error
context-length rejection, then APIConnectionError on one isolated item ->
that item's vector is retained.
The existing context-length, 401/403, 5xx, quota and rate-limit tests are
retained.
Local verification with the repo's own hook arguments:
pylint -> Your code has been rated at 10.00/10, exit 0
black -> 2 files would be left unchanged
flake8 -> clean
Branch-order discriminator check (classifiers extracted from the production
file and executed against each error type):
case old new
400 context-length SPLIT SPLIT
401 / 403 SPLIT STOP
500 SPLIT RETRY
SDK APIConnectionError SPLIT RETRY
SDK APITimeoutError SPLIT RETRY
builtin ConnectionError RETRY RETRY
builtin TimeoutError RETRY RETRY
429 RETRY RETRY
insufficient_quota STOP STOP
* fix(embedding): treat 404 as a provider-wide failure too
Fourth review follow-up on #579.
The classifier added in c9448ae covered 401/403 and 5xx, but not 404. A missing
model or a wrong embedding route answers with 404 (SDK `NotFoundError`), which
no individual input can explain, so the batch still fell through to
`_embed_individually()`: a ten-item request against a bad model name produced
eleven requests, all failing for the same reason.
404 is now part of the provider-wide set (`_PROVIDER_WIDE_STATUS_CODES`) and
`NotFoundError` joins the class-name fallback. Like 401/403 it is not
transient, so the request is reported as failed once instead of being retried
or split. The context-length `400` is deliberately left out of that set: an
over-limit item is the one status a single input can explain by itself, so it
has to stay isolatable.
Regression coverage:
- test_provider_wide_statuses_exclude_input_dependent_bad_request
401/403/404/500 -> provider-wide; an over-limit 400 -> not provider-wide.
- test_provider_wide_not_found_errors_are_not_split
404 -> batch sizes [10], no sleeps, no single-item requests.
The existing context-length isolation, 401/403, 5xx, quota, rate-limit and SDK
transport tests are retained.
Local verification with the repo's own hook arguments:
pylint -> Your code has been rated at 10.00/10, exit 0
black -> 2 files would be left unchanged
flake8 -> clean
Branch-order discriminator check (classifiers extracted from the production
file and executed against each error type):
case old new
400 context-length SPLIT SPLIT
401 / 403 SPLIT STOP
404 NotFoundError SPLIT STOP
500 SPLIT RETRY
SDK APIConnectionError SPLIT RETRY
SDK APITimeoutError SPLIT RETRY
builtin ConnectionError RETRY RETRY
builtin TimeoutError RETRY RETRY
429 RETRY RETRY
insufficient_quota STOP STOP
* fix(embedding): classify every provider status shape and split only input errors
The per-item fallback still multiplied service failures into one request per item.
Both gaps come from the fallback this PR adds, so they are fixed here.
Status extraction
- `_http_status()` reads the status from `status_code`, an integer `code` (Google GenAI
exposes the HTTP status there), `response.status_code` (httpx-style wrappers), and the
structured `status_code` embedded in the message (AgentScope's DashScope embedding turns
every non-200 response into a plain `RuntimeError`).
- Only integers are read from `code`. A string `code` names an error
(`insufficient_quota`, `rate_limit_exceeded`, `InvalidApiKey`); reading it as a status
would misclassify quota and rate-limit errors.
- `_is_provider_wide_failure`, `_is_transient_provider_failure`, `_is_rate_limited` and
`_is_input_dependent_failure` all classify through it.
Splitting
- The generic fallback splits only when `_is_input_dependent_failure()` matches: a
context-length rejection, the one error a single over-long item explains by itself.
Anything unrecognized is provider-wide and is never answered with one request per item.
- This narrows the isolation this PR adds. An input-dependent error that carries neither a
status nor an input-length signal is no longer split, so it costs its batch instead of
multiplying the requests. Erring towards the batch keeps one provider failure from
becoming N failures and losing the healthy vectors anyway.
- `_embed_individually()` drops the redundant `len(single) == 1` check: the
`_call_with_retry([text])` contract only returns a result of the expected length.
Verified against the real exception classes: `google.genai.errors.APIError.code` is an
`int`, and a real DashScope response yields a `RuntimeError` whose message carries
`"status_code"`. Regression coverage uses the real classes when available and mirrors
their shape otherwise.
* fix(embedding): stop per-item isolation on a provider-wide failure and read serialized codes
- `_embed_individually` now stops asking for the remaining items as soon as one isolated
item fails provider-wide (credentials, missing model, exhausted quota, exhausted
transient retries). No remaining input can explain that failure, so continuing only
multiplies the rejected requests. The vectors already recovered are kept and the items
that were never answered stay `None`.
- `_call_with_retry` reports that outcome through an optional `terminal_failure`
out-parameter, so its return type and every existing call site stay unchanged.
- `_error_code` reads the business error code from the attribute, the structured body, or
the serialized message. AgentScope's DashScope embedding raises a plain `RuntimeError`
with the response embedded in the message, so a quota error was classified as a rate
limit and never used the configured `quota_retry_delay`.
Regression tests cover both halves of the isolation boundary (a provider-wide failure
stops the loop; an input-dependent failure does not) and the serialized DashScope quota
path with quota retries enabled.
* fix(embedding): treat an input-length 413 as a per-item rejection
* fix(embedding): keep the health state after a partial success
`_compute_batch()` set `is_healthy = True` whenever the batch produced at least one
vector. Per-item isolation can recover an early item and then meet a provider-wide
failure (exhausted quota, authentication, exhausted transient retries), which
`_call_with_retry()` correctly records as unhealthy before it stops. The recovered
vector then overwrote that state, so a request that ended in an outage reported the
provider as healthy.
The terminal-failure flag is now threaded from `_embed_individually()` back to
`_compute_batch()`. The vectors recovered before the failure are still returned and
cached; only the health state now follows the failure. This matters because
`LocalFileStore._recover_after_real_request()` schedules missing-vector backfill off
the unhealthy-to-healthy transition: a hidden outage would either trigger backfill
while the provider is still unavailable or suppress a later genuine recovery.
Adds a regression test through `get_embeddings()` that checks both the retained
partial vector and the final unhealthy state. The existing isolation test covers
`_call_with_retry()` directly, so it never saw the overwrite.
* fix(embedding): leave provider 5xx retries to the layers that own them
A store-level retry for a provider 5xx stacked on top of the retries the
embedding wrapper and the provider SDK already perform, so a batch the SDK
answered after 12 attempts became 36. Retry ownership stays with those
layers; the store answers a provider-wide 5xx once and gives up.
Transport failures keep their retry because they describe a connection that
no lower layer has reported, and the opt-in quota policy is untouched.
Tests updated to pin the new boundary: a 503 is answered once for the
OpenAI-shaped, Gemini-shaped and DashScope-shaped errors, while a 429 keeps
its retry from the rate-limit branch.
* fix(embedding): make transport retry ownership explicit
The store retried a connection failure or a timeout on top of the embedding
wrapper and the provider SDK, which already retry both, so a persistent
timeout on a batch reached the provider 36 times instead of 12: the OpenAI
model retries a batch max_retries + 1 times and the SDK retries each of those
attempts.
Transport failures stay provider-wide -- the request is never split per item
-- but the retry is now owned explicitly instead of implicitly:
* a whole-batch request leaves it to the layers below, which already retry it;
* an isolated single-item attempt keeps the store's backoff, because that
attempt is the last chance to keep the one vector the isolation step is
recovering.
Rate limiting is unchanged. The transport cases now pin both budgets, and
three tests drive a real OpenAIAsEmbedding wrapper and a real
openai.AsyncClient over an httpx.MockTransport, so the provider attempt count
is measured rather than assumed.
* fix(embedding): check the failing error against the provider retry policy
* fix(auto-memory): serialize session transcript writes per session
_save_session_messages ran its read-merge-write on the per-session
JSONL transcript without any lock. Concurrent HTTP requests saving the
same session could interleave: two writers both appending against a
stale snapshot write overlapping history twice, and an append racing
a full rewrite can be overwritten by the rewriter's stale merge,
losing messages.
Hold get_path_lock(path) across the whole read, merge, and write,
consistent with the existing session image handling in the same file.
Merge, ordering, and can_append logic are unchanged.
Add deterministic regression tests that gate one writer's read between
snapshot capture and write: concurrent appends must merge disjoint
messages in created_at order, and an appended message must survive a
concurrent full rewrite. Both tests fail without the lock.
Closes#622
* test(auto-memory): make session-lock regression tests deterministic
Replace fixed sleeps with explicit synchronization: a shared operation
log records lock/read/write progress per writer, and writer A holds its
post-read pause until writer B is queued on the transcript lock. The
tests now assert the serialization order from the log (B reads only
after A's write completed) in addition to transcript content, so they
no longer depend on IO timing.
Also fix pylint findings from CI: use from-import for the auto_memory
module and drop unused tmp_path parameters.
* fix(agent_wrapper): release Codex threads after each turn
Loaded Codex threads and their per-thread MCP server subprocesses were
never unloaded from the app-server, growing file descriptors and child
processes monotonically until the wrapper was closed (fd exhaustion,
os error 24). Reply, streaming reply, and compact_session now
unsubscribe the thread in a turn-scoped finally block by default; the
new release_threads=False option restores the previous behavior.
Unsubscribe failures are logged and never break the turn, and threads
remain resumable after being unloaded.
Closesagentscope-ai/ReMe#609
* fix(agent_wrapper): keep tool-context guard on failed release and cover stream startup
A failed thread/unsubscribe left the thread loaded in the app-server
but dropped its tool-context entry, so a later resume with changed
tool_context_id or injected_job_kwargs would silently bypass the
constraint check. Keep the guard entry unless the unsubscribe request
succeeds.
reply_stream now releases the thread from an outer try/finally scoped
right after _open_thread, so threads are also unloaded when turn/start
raises or the caller is cancelled while awaiting it.
