Skip to content

feature: document Kustainer emulator container-recreate reattach in azure-kusto skill - #2925

Closed
Brett Wilson (MSBrett) wants to merge 1 commit into
microsoft:mainfrom
MSBrett:extend/azure-kusto-emulator-reattach
Closed

feature: document Kustainer emulator container-recreate reattach in azure-kusto skill#2925
Brett Wilson (MSBrett) wants to merge 1 commit into
microsoft:mainfrom
MSBrett:extend/azure-kusto-emulator-reattach

Conversation

@MSBrett

Copy link
Copy Markdown

What

Adds a "Local Kusto Emulator (Kustainer / Docker)" section to plugin/skills/azure-kusto/SKILL.md, documenting how to reattach a previously-persisted database after the emulator container is stopped/removed and recreated against the same /kustodata bind mount. Also adds a one-line pointer in "Common Issues".

Why

Recreating the Kustainer container (e.g. to bump --memory) does not auto-reattach existing databases - only the empty built-in NetDefaultDB is created on engine start. The instinctive fix (re-running the canonical creation command, .create database ... persist(...)) fails with a generic Internal service error when pointed at metadata that already exists on disk, which is easy to misread as data loss. The correct command is the distinct .attach database <name> from @"<md-path>", which registers existing metadata in milliseconds without touching any data files.

This was root-caused via live, first-party incident reproduction: the failing .create ... persist(...) command failed identically and near-instantly (flat CPU/memory) on both a 408KB and a 49GB database, ruling out size/resource causes; .attach database ... from succeeded in ~0.15s for both, and post-attach row counts matched pre-incident ground truth exactly on a 40M+ row table.

Scope

Documentation only - no new MCP tools, activation triggers, or frontmatter changes.

Validation

  • npm run checkCopilotCliCharBudget (scripts/): passes, unaffected (description text unchanged).
  • npm run frontmatter -- plugin/skills/azure-kusto/SKILL.md (scripts/): only the pre-existing metadata.version "0.0.0-placeholder" notice appears, confirmed present identically on an untouched skill (azure-storage) - i.e. unrelated to this change and expected pre-build (versions are stamped by Nerdbank.GitVersioning at build time per docs/Onboarding.md).
  • Manual token estimate: SKILL.md is ~2.7k tokens post-change, within the 5k token guidance.
  • Did not run the full vally eval suite in this environment (requires live agent/Azure integration); this is a targeted textual addition to an existing skill's "Common Issues"/reference material, not a new skill or new trigger surface.

Closes #2924

…zure-kusto skill

Adds a "Local Kusto Emulator (Kustainer / Docker)" section to the
azure-kusto skill documenting the correct way to reattach a previously
persisted database after the emulator container is stopped/removed and
recreated against the same /kustodata bind mount.

Root cause documented: `.create database ... persist(...)` is for
first-time creation and fails with a generic, unhelpful
`Internal service error` when pointed at metadata that already exists
on disk (reproduced identically on both a 408KB and a 49GB database,
ruling out size/resource causes). The correct reattach command is
`.attach database <name> from @"<md-path>"`, which registers existing
metadata in milliseconds without touching data files.

Also adds a one-line pointer in "Common Issues" for discoverability.

Verified via live, first-party incident reproduction: post-attach row
counts matched pre-incident ground truth exactly on a 40M+ row table.

Closes microsoft#2924

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds documentation to the azure-kusto skill clarifying how to persist and reattach databases when using the local Azure Data Explorer Docker emulator (Kustainer), specifically addressing the common “database disappeared after container recreation” scenario.

Changes:

  • Adds a new “Local Kusto Emulator (Kustainer / Docker)” section explaining persist paths and the correct .attach database ... from reattach workflow after container recreation.
  • Updates “Common Issues” with a direct pointer to use .attach database (not .create ... persist(...)) when the emulator container is restarted/recreated.


## Local Kusto Emulator (Kustainer / Docker)

Azure Data Explorer ships a Docker emulator (`mcr.microsoft.com/azuredataexplorer/kustainer-linux`) for offline/local development. It exposes the same REST endpoints (`/v1/rest/query`, `/v1/rest/mgmt`) as a real cluster, but has emulator-specific lifecycle behavior that differs from a managed ADX cluster.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please create a reference file for the local development instructions and link from here?

@github-actions

Copy link
Copy Markdown
Contributor

This PR has been automatically closed because it has unresolved review comments and no new commits in the last 28 days.

If you would still like to merge these changes, please:

  1. Resolve all outstanding review comments
  2. Reopen this PR

Thank you for your contribution!

@github-actions github-actions Bot closed this Aug 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Add Capability]: azure-kusto - document local Kustainer emulator container-recreate reattach (.attach database vs .create ... persist)

4 participants