v1.0.14

NotiOps v1.0.14

A teardown-path patch on top of v1.0.13. Deleting a deployment had two
defects: one made the stack delete fail outright, and one silently left a
resource behind while reporting success. Nothing here changes a running
deployment — if you are not deleting anything, there is no urgency to update.
But "try it, then delete it" is the most common thing anyone does with a sample
repo, so this is worth taking.

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

Fixes

• Deleting the stack with TeardownMode=DeleteEverything could fail on the
  data bucket. Right after a bucket is emptied, S3 frequently rejects the
  immediately-following DeleteBucket with OperationAborted — "a conflicting
  conditional operation is currently in progress against this resource" — because
  the batch of object deletions is still settling. On this path the error is
  deliberately allowed to propagate (you asked for everything to be deleted;
  quietly keeping your data would be worse than stopping), so with no retry the
  stack went straight to DELETE_FAILED. Deleting the stack a second time
  succeeded, which is exactly why this is easy to write off as a one-off. The
  delete is now retried for up to 30 seconds.

• The stack silently failed to delete the web-search gateway it had created.
  Deleting a gateway target is asynchronous: the DELETE returning success only
  means the deletion started. Teardown deleted the target and immediately
  deleted the gateway, which the service rejects while a target is still
  attached — and on the teardown path that error is swallowed on purpose (leaving
  one orphan behind is better than wedging your whole stack in DELETE_FAILED).
  The result was a silent failure: the stack deleted cleanly and reported
  success, while an AgentCore gateway named notiops-websearch-gw stayed behind
  in READY, contradicting what the documentation promises. Teardown now waits
  for the targets to actually be gone before deleting the gateway.

  If you deployed v1.0.13 in us-east-1 and have already deleted the stack,
  check for a leftover gateway — it is tagged project=notiops:

  aws bedrock-agentcore-control list-gateways --region us-east-1 \
    --query "items[?name=='notiops-websearch-gw']"
  # if it is there and nothing else uses it:
  aws bedrock-agentcore-control delete-gateway --region us-east-1 \
    --gateway-identifier <gatewayId>

  An orphan cannot serve searches (its target was deleted) and is not billed for
  being idle, so this is hygiene rather than cost. Note that a later redeploy
  finds the same-named gateway and reuses it, so nothing stays broken.

• The v1.0.13 "replace a FAILED gateway" fix rested on the same faulty
  helper. It shares the delete routine above, and on that path the error is
  raised rather than swallowed — so instead of leaking a resource, provisioning
  degraded to WebSearchProvisioning: unavailable (…) whenever the dead gateway
  still had a target attached. Fixed by the same change.

• setup.sh had both bugs too. teardown.sh and
  scripts/provision_websearch_gateway.sh used the same delete-then-immediately-
  delete sequence, each with the failure suppressed, so they were just as silent.
  Both now wait for the targets to disappear.

Upgrading

Nothing about this release affects a running deployment, so you only need it
before you next delete one — but the fix has to be in the stack before the
delete, because CloudFormation hands a custom resource the values from the last
successful deployment, not the ones you wish it had at delete time.

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. 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.14
./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)

f4ece748f4f0643d344e991a1196562edb2cb56d418aab84475f22554a00d714  bff.zip
f23d5c94991422bae16c11c81dcb60457f677526b667f0cb18c0e8baf06da2f6  chat-dist.zip
2ac1b628cfc23954348c6c7438775c2e3cbb4deea230d31a0bcfa55edd1b1623  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.