Skip to content

NotiOps v1.0.18

Choose a tag to compare

View all tags
@xiuleiyy xiuleiyy released this 30 Aug 06:43
· 1 commit to main since this release
v1.0.18
5d1c7ae

NotiOps v1.0.18

This release is about the wait before the first word. Asking a question after
the chat has been idle used to take 23.4 seconds before anything appeared;
it now takes 10.1 seconds — measured, same account, same prompts. Most of
that came from a bug rather than from physics: long-term memory retrieval was
silently failing on every turn, and four wasted service round trips were sitting
in front of your answer. Both deployment paths upgrade in place; nothing about
your data or your configuration changes.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

  • First response after idle: 23.4s → 10.1s (−57%). The agent runs on
    Bedrock AgentCore, which isolates by session, so every new conversation is a
    genuine cold start — and before a single tool can be mounted the agent needs
    the tool schemas, which until now meant starting all five stdio MCP servers
    and calling list_tools on each. The slowest one alone measured 9.3s, and all
    of it landed in front of your first token. Three changes, in the order they
    matter:

    1. Memory retrieval no longer wastes four round trips per turn (see
      Fixes — it was also returning nothing).
    2. The five MCP servers start in parallel instead of one after another.
    3. Tool schemas are cached in your own S3 bucket under a new
      mcp-snapshots/ prefix. A new session mounts its tools straight from the
      snapshot and warms the subprocesses in the background, so the startup cost
      no longer sits in the critical path. The object key includes a fingerprint
      of the installed MCP package versions, so upgrading any MCP server
      invalidates the cache by itself — there is no snapshot to remember to
      clear. Reads and writes are both fail-safe: if the snapshot is missing,
      unreadable, or not writable, the agent falls back to today's slower path
      (start the servers first) and still answers correctly. The snapshots hold
      tool schemas only — no conversation content, no account data — and never
      leave your account.

    Measured with scripts/measure_cold_start.py --runs 5, a fresh
    runtimeSessionId per run (reusing a session measures the warm path, ~0.3s,
    not a cold start): general chat 10.14s, FinOps 10.32s, against 23.4s
    before. The very first session after deploying a new runtime version can
    still take ~30s, because the container image has to be pulled once.

  • The waiting message tells you the truth again. The heartbeat shown while a
    cold start is in progress said "first request after idle, ~30s". It now says
    ~10s, and the third message still absorbs the long tail rather than quoting a
    worst case at everyone.

Fixes

  • Long-term memory was silently retrieving nothing, on every turn. The
    retrieval query is supposed to be your question. What was actually sent was
    the fully assembled prompt — account-isolation rules, topic directive, skill
    body, forced web-search results, language lock — routinely tens of KB. AgentCore
    Memory rejects a searchQuery over 10,000 characters with a
    ValidationException, and the SDK turns that into an empty result list, so
    all four namespaces returned nothing and the failure was invisible: no
    error surfaced, memory simply appeared not to remember anything, and each turn
    still paid for four round trips to find that out.

    The query is now the user's raw question (capped at 4,000 characters), swapped
    in only for the retrieval call so the model still receives the complete prompt.
    Long-term memory across sessions now actually works — if you noticed the
    assistant forgetting things you had told it in earlier sessions, that was this.

  • npm test in infra/ could run out of heap. ts-jest builds a TypeScript
    LanguageService over the whole program, including the very large aws-cdk-lib
    type declarations — about 700 MB of heap per suite, while the CDK synthesis
    the tests actually exercise needs only 60–120 MB. On a small CI runner (one
    worker, both suites in one process, ~990 MB default old-space limit) that is a
    hard Reached heap limit — allocation failed crash. The new
    infra/tsconfig.jest.json switches ts-jest to transpile-only: peak heap per
    suite drops from 774 MB to 64 MB and from 799 MB to 117 MB. Type checking
    moves to npx tsc --noEmit -p tsconfig.jest.json, whose include also covers
    test/** — so coverage went up, not down. The memory limit was deliberately
    not raised: a 9× headroom is worth more than a 1.02× one.

Upgrading

setup.sh:

git pull            # or re-clone at tag v1.0.18
./setup.sh          # re-run; existing resources are updated in place

The agent's runtime role gains one permission — s3:GetObject / s3:PutObject
on the mcp-snapshots/* prefix of your existing data bucket — and the snapshot
is built on the first session that runs without one. The IM (Slack / Feishu /
DingTalk) task roles get the same permission, because those containers share the
MCP modules; without it they log AccessDenied and quietly take the slow path,
which works but looks like a fault.

Parallel MCP startup requires strands-agents >= 1.52.0 (earlier versions
patch MCP instrumentation globally without an idempotency guard, so constructing
clients concurrently stacks wrappers). pyproject.toml pins that floor and the
deployment installs it for you; no action needed.

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below and update your stack with it — Replace existing template, then
Use existing value for every parameter. Your data is not touched: the
conversation and configuration tables are Retain, and re-seeding is idempotent.
This upgrade does not resend the invitation email, change the admin credentials,
revert Admin settings, or clear chat history.

Do not mix assets across releases — the template and the four .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

5d9c8b3248f752c530b03fc60c8a8b881661b1ac51b60292d1f64a2e5bb05fe7  bff.zip
f44e48fc03eceeb02cb62f111b0ecdd66c6a72a996879558b33195f750ae10cd  chat-dist.zip
562440c873bbf88e558ffbf6ef4d8e3ad80204f4404b78a1d996da7167f5ef89  web-notif.zip
d77c924a6d11898db9c46d85bb4b51273b92b6cf41b1965bde82284782ddc5c8  agent-code.zip

Download notiops-webchat.template.json only. The four .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

Assets 8
Loading