[bug-bash] Sequential script commands leak their result into rm as implicit pipe input

Offen
  • Stimmt etwas nicht?
#281 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@mkrueger arbeitet bereits daran.

Seit 04.11.2026.

  • #292 von @mkrueger — offen

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
75/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
azure, cli, csharp
Bereich
cli, databases

Rechercherichtung

Start by reading RmCommand.ExecuteAsync and its container visitor, where the issue says pipe input is inferred from commandState.Result. Trace how sequential script statements carry CommandState into rm and compare that with a standalone rm invocation. Add or locate a regression test for the script sequence; done means exact-ID dry runs return count 1 with id and etag after an earlier command, without requiring an explicit pipeline.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug bug-bash

Environment

Windows x64, CosmosDBShell 1.1.291-preview (db49321323).
Reproduced against a disposable Azure NoSQL container with partition key /pk,
using Azure CLI authentication and Gateway mode.

Setup

PowerShell setup creates a unique disposable shared-throughput database
(400 RU/s), an Items container partitioned by /pk, and one synthetic item.
No existing data is required. Set the three account environment variables first:

foreach ($name in @('COSMOS_ENDPOINT', 'AZURE_SUBSCRIPTION_ID', 'COSMOS_RESOURCE_GROUP')) {
    if ([string]::IsNullOrWhiteSpace([Environment]::GetEnvironmentVariable($name))) {
        throw "Set $name to an authorized test account value before continuing."
    }
}
$package = "$env:USERPROFILE\.dotnet\tools\.store\cosmosdbshell\1.1.291-preview"
$shell = Join-Path $package 'cosmosdbshell.win-x64\1.1.291-preview\tools\net10.0\win-x64\CosmosDBShell.exe'
& $shell --version
$connection = @(
    '--connect', $env:COSMOS_ENDPOINT,
    '--connect-azure-cli', '--connect-mode', 'gateway',
    '--connect-subscription', $env:AZURE_SUBSCRIPTION_ID,
    '--connect-resource-group', $env:COSMOS_RESOURCE_GROUP,
    '--output', 'json', '--quiet'
)
$work = Join-Path ([IO.Path]::GetTempPath()) ('cosmos-rm-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Path $work | Out-Null
Set-Location $work
$db = 'BugBash_Rm_' + [guid]::NewGuid().ToString('N')
& $shell @connection -c "mkdb $db --scale=m --ru=400"
if ($LASTEXITCODE -ne 0) { throw 'Fixture database creation failed; stop.' }
& $shell @connection --database $db -c 'mkcon Items /pk'
if ($LASTEXITCODE -ne 0) { throw 'Fixture container creation failed; stop.' }
'[{"id":"safe-a","pk":"p1","count":1}]' | Set-Content -Encoding utf8 .\seed.json
& $shell @connection --database $db --container Items -c 'import seed.json --concurrency=1'
if ($LASTEXITCODE -ne 0) { throw 'Fixture import failed; stop.' }

Repro

Create and execute the exact failing script:

@"
cd /$db/Items
rm safe-a --key=id --partition-key=p1 --dry-run > preview.json
"@ | Set-Content -Encoding utf8 .\repro.csh
& $shell @connection -c 'repro.csh'
$previewExit = $LASTEXITCODE
Get-Content -Raw .\preview.json
"Exit code: $previewExit"

There is no pipe operator.

Expected

The exact-ID dry run should independently read the existing item and return
count 1, id "safe-a", partitionKey "p1", and the current etag.

Actual

The process exits 0 and preview.json contains:

{"type":"item","count":0,"dryRun":true,"partitionKey":"p1"}

The item still exists. Running the same rm command as the sole command in a
fresh invocation returns count 1 with id and etag.

Working control: run the same exact-ID dry run as the only command, selecting
the target through startup options instead of a preceding cd:

& $shell @connection --database $db --container Items -c 'rm safe-a --key=id --partition-key=p1 --dry-run'

Actual: count 1, id "safe-a", partitionKey "p1", and the current etag.

A second exact script variant also demonstrates the leak:

@'
print safe-a p1 > before.json
rm safe-a --key=id --partition-key=p1 --dry-run > after-print.json
'@ | Set-Content -Encoding utf8 .\after-print.csh
& $shell @connection --database $db --container Items -c 'after-print.csh'
Get-Content -Raw .\after-print.json

Here count is 1, but id and etag are absent. The prior point-read result is
incorrectly interpreted as piped input, bypassing exact-ID preview behavior.
An automation step that subsequently reads preview.etag therefore fails.

Controls and impact

  • The point read confirmed the item exists.
  • A fresh single-command preview returned count 1 and the current etag.
  • Explicitly clearing the previous result with a helper script containing only
    return, between cd and rm, restored count 1, id, and etag.
  • A separate single-command deletion using the verified ETag deleted exactly
    one item; a subsequent point read confirmed it absent.
  • These controls distinguish the bug from missing fixture data or failed import.
  • This can silently turn script deletion/preview steps into no-ops or remove
    fields needed by ETag-protected automation. No unintended deletion was observed.

Investigation lead

RmCommand.ExecuteAsync and its container visitor infer pipe input solely from
commandState.Result != null. Script execution carries CommandState between
sequential statements, allowing an earlier cd/print result to satisfy that test
without an explicit pipeline. Exact-ID mode is bypassed when hasPipeInput is true.

Workaround: run the exact-ID operation in a separate invocation, using startup
database/container options rather than a preceding cd statement.

Cleanup

The failing operations above are dry runs and delete no items. Delete only the
database created by the setup commands when finished:

& $shell @connection -c "rmdb $db true"

The databases used during the original tests were deleted and independently
verified absent through Azure Resource Manager. No product fix was implemented.

Vorherrschende Sprache
C#
Sterne
4
Forks
7
Ø Merge
1 T. 23 Std.
Gemergte PRs (30 T.)
23

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Azure/CosmosDBShell

Alle Issues in Azure/CosmosDBShell

Ähnliche Issues

Weitere Issues zu C#

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.