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

Ouverte
  • Quelque chose ne va pas ?
#281 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
75/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
azure, cli, csharp
Domaine
cli, databases

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
C#
Étoiles
4
Forks
7
Merge moyen
2 j 2 h
PR mergées (30 j)
24

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Azure/CosmosDBShell

Toutes les issues de Azure/CosmosDBShell

Issues similaires

Plus d'issues C#

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.