Skip to content

NotiOps v1.0.13

Choose a tag to compare

View all tags
@xiuleiyy xiuleiyy released this 26 Aug 04:33
· 6 commits to main since this release
v1.0.13
a5ef25d

NotiOps v1.0.13

The two deployment paths now install the same web console. Both paths have
always shipped the same agent, the same frontend, and the same BFF — the only
difference was supposed to be who creates the resources. In practice the
one-click stack was missing the web-search gateway and the IAM that goes with
it, so the
web-search toggle in the chat input bar rendered and clicked but never
returned anything. This release closes that gap, adds a CI check that fails the
build if the two paths drift again, and makes web search AWS-native on both
paths (no third-party API key, and the query text never leaves AWS).

If you deployed with the one-click template, update your stack to get web
search — see Upgrading.

⚠️ 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

  • Web search on the one-click path. The stack now creates the Bedrock
    AgentCore gateway (notiops-websearch-gw) with the AWS built-in web-search
    connector target, and grants the agent runtime bedrock-agentcore:InvokeGateway
    — the two things the toggle needed. There is no parameter to fill in: no
    API key, no endpoint, nothing to configure. Billing is per search, so it only
    costs anything when a user turns the toggle on and the agent decides to
    search.

    Two behaviours worth knowing:

    • us-east-1 only. That is where the AgentCore web-search API is
      available today. Deploying into any other Region still succeeds — the
      web-search resources are skipped as a block and the new WebSearchStatus
      stack output tells you why. Note the toggle is not greyed out in other
      Regions (the UI does no Region check): clicking it does not error, you just
      get no results.
    • Two outputs, because "the Region supports it" and "it actually got
      built" are different questions.       WebSearchStatus answers the first;
      the new WebSearchProvisioning output answers the second — enabled
      means the toggle works, unavailable (<code>) means it does not.
      Provisioning deliberately never fails the stack (losing every other
      feature over one optional toggle would be a bad trade), which is exactly
      why the result needs its own output.
    • An existing gateway is reused, not duplicated — and not deleted. If the
      account already has a notiops-websearch-gw (for example because you ran
      ./setup.sh first, or you have a second stack in the same account), the
      stack reuses it. Whether it created or reused is recorded, and deleting the
      stack only removes a gateway that this stack created. Tearing down one
      deployment does not break another one that is still using it.

  • Web search is AWS-native only; the third-party fallback is gone. Both
    paths previously fell back to a public third-party search endpoint when the
    AWS-native gateway was unavailable, which meant the query text could leave
    AWS and, on the one-click path, required you to bring your own API key. That
    fallback has been removed from both paths. Web search is now exactly one
    implementation — the AgentCore web-search connector — so "web search is on"
    has a single, checkable meaning. If the gateway is not configured for a
    deployment, web search reports itself as unavailable instead of quietly
    routing your query somewhere else.

Fixes

  • A deployment without a working gateway now says "no web search" instead of
    timing out on every search.     The gateway URL is only accepted if it starts
    with https://; anything else counts as "not configured". Previously the two
    values that actually turn up there — the un-substituted
    __WEBSEARCH_GATEWAY_URL__ placeholder you get from running agentcore deploy
    by hand instead of scripts/deploy_agent.sh, and the unavailable marker the
    one-click stager writes when it could not provision the gateway — were treated
    as real endpoints, so each search SigV4-signed a request to a garbage host and
    waited out the HTTP timeout.
  • The scaffold that actually gets deployed said web search used a third-party
    engine.     That note reached the model in a tool description, so the assistant
    could tell a user their query had left AWS when it had not. It now matches
    reality.
  • The one-click stack could not finish building the gateway it created. The
    role that provisions it was missing bedrock-agentcore:CreateWorkloadIdentity
    on the account's default workload-identity directory. CreateGateway returns
    success without it and the gateway then goes FAILED asynchronously —
    "Failed to create gateway dependencies" — so the stack reached
    CREATE_COMPLETE next to a dead gateway. setup.sh never hit this because it
    provisions with the deployer's (usually administrator) credentials.
  • A gateway stuck in FAILED is now replaced instead of reused forever.
    Both paths look up the gateway by name and reuse what they find, which turned
    one bad first attempt into a permanent condition: every later deploy waited
    for the same dead gateway to become ready. A FAILED gateway cannot serve
    anything, so both paths now delete it and build a new one. Gateways in any
    working state are still reused untouched.
  • setup.sh no longer hands the agent a gateway URL that does not work. If
    the gateway never reaches READY, scripts/provision_websearch_gateway.sh
    now fails loudly (pointing at statusReasons and the permission above)
    instead of printing the URL anyway. The deployment continues without web
    search, which is the honest outcome — previously the agent was configured
    with a URL that timed out on every search.

Docs

  • docs/DEPLOYMENT_ONECLICK.md / .en.md: web search moved out of the "not
    included" list into its own section covering billing, the us-east-1
    restriction, and the reuse/delete semantics; WebSearchStatus and
    WebSearchProvisioning added to the outputs table; the resource count corrected to 50 with the default
    parameters (+3 in us-east-1, −4 with deep investigation off, +3 for
    multi-account), and the rows for the reports CDN and the web-search resources
    filled in.
  • README feature comparison: a web-search row, and two corrections where the
    one-click column understated it — Bedrock API key as the credential and
    permanent links for long reports are both supported on the one-click path
    (the secret is created on demand by the BFF on either path, and the reports
    CDN is inside the stack).
  • docs/USER_GUIDE.md / .en.md: the web-search toggle only does something in
    us-east-1, so a user who gets no results knows it is a deployment Region
    question, not a broken assistant.

Under the hood

  • A new source-level check asserts that the agent runtime execution role gets
    the same set of IAM actions and the same set of injected environment
    variable keys     on both deployment paths, with wildcard awareness
    (ce:List* covers ce:ListCostAllocationTags). It fails loudly if it cannot
    locate the sections it compares, rather than passing silently — a check that
    can't find its input is not a passing check. The list of Regions the agent may
    reach is likewise asserted to be identical on both paths: "supported on both
    paths, but in different Regions" is its own kind of drift.

Upgrading

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 — a template update of this kind
takes a couple of minutes. In us-east-1 it adds the web-search gateway; in
other Regions the web-search resources stay skipped. Upgrading does not resend the invitation email, change the
admin credentials, revert Admin settings, or clear chat history.

setup.sh:

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

Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent.

Do not mix assets across releases — the template and the three .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)

7f970584ece8527dcdf4649dd8f39a0c50242f14b858be1b8e82364f9b54de2f  bff.zip
83ffe7b2439b01e275de1d608d02de8195acc6c6442fd2076d159a5cb5cec969  chat-dist.zip
88448ea790397c68edce183e19a29e235fb3b739e0a9d4e0c17b1de0502784ba  agent-code.zip

Download notiops-webchat.template.json only. The three .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 7
Loading