fix(2.8.1): Sechs Befunde, eine Bauart - die Voreinstellung, die einsprang

Drei Agenten haben von aussen gemeldet, und fast jeder Befund hat dieselbe
Form: Irgendwo sprang ein Vorgabewert ein, obwohl die richtige Antwort
bekannt war - meist das Projekt, an das der Aufrufer ohnehin gebunden ist.

#351  manage?action=next antwortete durchgaengig mit HTTP 500. In
      BugRepo::buildFilter() stand :project_scope zweimal in derselben
      Anweisung; mit ATTR_EMULATE_PREPARES=false bindet PDO jeden Namen
      genau einmal - zwei Marker, ein Wert, SQLSTATE[HY093]. Getroffen war
      nur "next", weil nur dort der Rueckkanal-Filter gesetzt wird. Damit
      gab es keine exklusive Uebernahme. Es ist der VIERTE Fall dieser
      Bauart, deshalb prueft scripts/pruefe_platzhalter.py das jetzt
      mechanisch vor jedem Ausliefern.

#382  Meldungen ohne project_slug landeten im Scheinprojekt "default" -
#387  ohne dc_projects-Zeile, also project_id NULL. Die Antwort sah wie ein
#397  Erfolg aus, und danach sperrte dieselbe Token-Bindung den Zugriff
      (403 project_forbidden). Der Rueckfall aufs Heimatprojekt war an
      !isWorkbench gebunden; ein Werkbank-Token ohne Slug bekam gar keinen
      Vorgabewert. Jetzt: genannter Slug, sonst Heimatprojekt, sonst 400.
      Ein unbekanntes Projekt wird abgewiesen statt still angelegt.

#364  Ohne project_slug lieferten list, stats und die Roadmap ALLE
#176  Projekte statt des eigenen, weil die Vorgabe auf "all" stand und ein
      Werkbank-Token beim Lesen absichtlich nicht unter die Schranke faellt.
      Gemessen: 393 Items, davon 28 eigene. Ausgerechnet der erste Aufruf
      jeder Sitzung. Die Roadmap antwortet ausserdem schmal - 55 Felder je
      Eintrag waren 628.392 Zeichen und fuellten das Kontextfenster.

#404  Watchdog-Monitore bekamen nie ein Projekt: upsertHeartbeat() wurde
      keines uebergeben, obwohl authorizeSource() die Token-Bindung liest.
      Befunde erbten dadurch "default" - dc_findings(project_slug=...) war
      fuer eine laufende, meldende Instanz leer.

#131  Wo der Leseweg richtig verengte, sagte er es nicht: HTTP 200 mit dem
      umgeschriebenen Filter sieht aus wie eine Auskunft ueber das
      angefragte Projekt. Ein Agent, der vor dem Melden dc_search fragt,
      legt so das Duplikat an. Jetzt scoped_to und scope_note im Umschlag -
      nur bei tatsaechlicher Verengung.

#354  dc-testkit 1.1.0 wurde zweimal mit verschiedenem Inhalt ausgeliefert
      (1898 und 1930 Zeilen), 1.0.0 davor ebenso. Der Absatz ueber
      DC_TESTKIT_VERSION stand die ganze Zeit im Skript und hat nicht
      getragen. Jetzt 1.1.1 plus ein Riegel in deploy.py, der abbricht,
      wenn sich der Inhalt aendert und die Nummer nicht.

Warum die Testsuite all das nicht sah: Ihr Master-Token ist an kein Projekt
gebunden und nimmt deshalb ueberall den anderen Zweig. Es gab sogar einen
Testfall fuer action=next - er lief gruen, waehrend der Aufruf in der Praxis
ausnahmslos scheiterte. Die neuen Faelle benutzen ausdruecklich
projektgebundene Token; testctl kann dafuer jetzt owner_type und scopes
waehlen.

Ausserdem: Die Agentenvorlage nennt fuer die SDK-Fassung dc_link_project
statt einer abgeschriebenen Zahl - "SDK 2.5.1" stand dort als Beispiel und
wurde als Wert uebernommen.

Nicht enthalten: die 20 Altlasten in "default". Sie sind ueber die API nicht
erreichbar; sql/wartung/2026-08-31_default-projekt-aufraeumen.sql liegt dafuer
bereit (alle 20 haben einen titelgleichen Zwilling im richtigen Projekt).

156 e2e-Faelle gruen, davon 9 neue.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Deploymentcenter Bot
2026-08-31 20:43:23 +02:00
co-authored by Claude Opus 5
parent 8274a6c0ac
commit 0e93345ab8
20 changed files with 1394 additions and 56 deletions
+44
View File
@@ -219,6 +219,50 @@ final class ApiAuth
return is_string($bound) && $bound !== '' ? $bound : null;
}
/**
* Sagt es, wenn eine Antwort ein anderes Projekt betrifft als das angefragte.
*
* DAS PROBLEM IST DIE STILLE, nicht die Verengung. Ein an Projekt X
* gebundenes Token, das nach Projekt Y fragt, bekommt beim SCHREIBEN eine
* klare Absage (403 project_forbidden) und beim LESEN HTTP 200 - mit den
* Items von X und einem Umschlag, in dem der Projektfilter bereits auf X
* umgeschrieben ist. Die Antwort sieht damit aus wie eine gueltige
* Auskunft ueber Y.
*
* Das ist keine theoretische Verwechslung: Die Prompt-Vorlage schickt
* jeden Agenten vor jeder Meldung durch dc_search ("gibt es das schon?").
* Mit der falschen Tokenart bekommt er auf "gibt es das im
* Deploymentcenter schon?" eine leere, plausibel aussehende Antwort - und
* legt das Duplikat an. Genau so ist es einem Melder beinahe passiert;
* tatsaechlich waren es 71 Items.
*
* Die Schranke bleibt unveraendert. Sie sagt jetzt nur, dass sie zugegangen
* ist. (#131)
*
* @param ?string $requested Was der Aufrufer angefragt hat, oder null.
* @param string $actual Worueber tatsaechlich geantwortet wird.
* @return array{scoped_to?:string,scope_note?:string} Leer, wenn nichts verengt wurde.
*/
public static function scopeNotice(?string $requested, string $actual): array
{
if ($requested === null || $requested === '' || $requested === $actual) {
return [];
}
return [
'scoped_to' => $actual,
'scope_note' => sprintf(
'Angefragt war "%s", geantwortet wird ueber "%s": Dieses Token ist an "%s" '
. 'gebunden. Die Antwort sagt NICHTS ueber "%s" aus - insbesondere heisst eine '
. 'leere Liste hier nicht, dass es dort nichts gibt.',
$requested,
$actual,
$actual,
$requested
),
];
}
private static function stringOrNull($value): ?string
{
if (!is_string($value)) {
+121 -5
View File
@@ -159,13 +159,50 @@ final class BugRepo
// ==================================================================
/**
* Nimmt einen Bug, Feature Request oder eine Idee entgegen.
* Nimmt eine Meldung entgegen und liefert, was daraus geworden ist.
*
* @return array<string,mixed>
* Der Mantel um reportItemIntern() tut zwei Dinge, die jede Rueckgabe
* betreffen und deshalb nicht in jedem einzelnen return stehen sollen:
*
* 1. Er BESTEHT auf einem Zielprojekt. Hier stand einmal
* "?? 'default'" - eine Voreinstellung, die aussah wie eine
* Hoeflichkeit und eine Falltuer war: 'default' ist kein Projekt,
* es hat keine dc_projects-Zeile, also blieb project_id NULL. Die
* Meldung war angelegt, quittiert - und fuer den Melder unerreichbar,
* weil sein Token an ein anderes Projekt gebunden ist. Wer nicht
* weiss, wohin eine Meldung gehoert, soll das erfahren, nicht raten.
* 2. Er schreibt project_slug in die Antwort. Ohne diese Angabe sah eine
* Meldung, die im Nichts landete, genauso aus wie eine, die ankam.
*
* @throws \InvalidArgumentException wenn kein Zielprojekt genannt ist
*/
public function reportItem(array $data): array
{
$projectSlug = self::text($data['project_slug'] ?? null) ?? 'default';
$projectSlug = self::text($data['project_slug'] ?? null);
if ($projectSlug === null) {
throw new \InvalidArgumentException(
'Eine Meldung braucht ein Zielprojekt (project_slug). Frueher fiel dieser Fall '
. 'auf das Scheinprojekt "default" zurueck; die Meldung war danach fuer den '
. 'Melder nicht mehr erreichbar.'
);
}
$result = $this->reportItemIntern($data, $projectSlug);
$result['project_slug'] = $projectSlug;
return $result;
}
/** Gibt es dieses Projekt wirklich? */
public function projectExists(string $slug): bool
{
return $this->projectIdForSlug($slug) !== null;
}
/** @param string $projectSlug Bereits geprueft, nie leer. */
private function reportItemIntern(array $data, string $projectSlug): array
{
$type = (($data['type'] ?? 'bug') === 'feature_request') ? 'feature_request' : 'bug';
$title = self::text($data['title'] ?? null)
@@ -895,9 +932,70 @@ final class BugRepo
// Abfragen
// ==================================================================
/**
* Die schmale Sicht auf ein Item.
*
* Ein bugtracker_item hat rund fuenfzig Spalten, darunter description,
* stack_trace, evidence, resolution_notes und context_json - jede fuer
* sich beliebig lang. Eine Liste von 57 Eintraegen kam so auf rund
* 137.000 Zeichen.
*
* Das ist nicht bloss unschoen. dc_roadmap ist laut CLAUDE.md der ERSTE
* Aufruf jeder Sitzung; ausgerechnet er fuellte damit das Kontextfenster,
* bevor die Arbeit begann. Eine Uebersicht beantwortet "was ist dran und
* wer sitzt dran" - dafuer braucht es keinen Stacktrace. Wer die Details
* eines Eintrags will, holt ihn einzeln (dc_get_item); dort stehen sie
* vollstaendig und genau einmal.
*
* @var list<string>
*/
public const COMPACT_FIELDS = [
'id',
'project_slug',
'type',
'title',
'status',
'severity',
'epic',
'roadmap_rank',
'target_build',
'claimed_by',
'lease_until',
'defer_trigger',
'doc_anchor',
'occurrence_count',
'environment',
'updated_at',
];
/**
* Schneidet ein Item auf COMPACT_FIELDS zurueck.
*
* Beschnitten wird in PHP, nicht in der SELECT-Liste: Welche Spalten eine
* Installation wirklich hat, haengt am Stand der Migrationen. Eine feste
* Spaltenliste im SQL wuerde auf einer Instanz, der eine Migration fehlt,
* mit einem Fehler abbrechen statt mit einem fehlenden Feld.
*
* @param array<string,mixed> $item
* @return array<string,mixed>
*/
private static function compactItem(array $item): array
{
$schmal = [];
foreach (self::COMPACT_FIELDS as $feld) {
if (array_key_exists($feld, $item)) {
$schmal[$feld] = $item[$feld];
}
}
return $schmal;
}
/**
* Gefilterte Liste. Unterstuetzt Pagination und Delta-Abfragen.
*
* fields=compact schneidet jeden Eintrag auf COMPACT_FIELDS zurueck.
*
* @return array{items:list<array<string,mixed>>,total:int,limit:int,offset:int,has_more:bool}
*/
public function getItems(array $filters = []): array
@@ -922,6 +1020,10 @@ final class BugRepo
$stmt->execute($params);
$items = $stmt->fetchAll() ?: [];
if (($filters['fields'] ?? null) === 'compact') {
$items = array_map([self::class, 'compactItem'], $items);
}
return [
'items' => $items,
'total' => $total,
@@ -998,11 +1100,25 @@ final class BugRepo
$affectedFor = $filters['include_affected_verification'] ?? null;
if (is_string($affectedFor) && $affectedFor !== '' && $affectedFor !== 'all') {
// ZWEI Platzhalter fuer denselben Wert, nicht einer zweimal.
//
// Hier stand :project_scope an beiden Stellen. Mit
// PDO::ATTR_EMULATE_PREPARES = false (siehe Core\Db) bereitet MySQL
// die Anweisung selbst vor: PDO uebersetzt benannte Platzhalter in
// positionsgebundene und bindet jeden Namen genau EINMAL. Die
// Anweisung hatte damit zwei Marker und bekam einen Wert - jeder
// Aufruf endete in SQLSTATE[HY093] und damit in HTTP 500.
//
// Getroffen hat es nur ?action=next: Nur dort wird
// include_affected_verification gesetzt. claim, release, list und
// stats laufen durch denselben Filter und blieben deshalb heil -
// was die Suche lange in die falsche Richtung geschickt hat.
$where[] = '(project_slug = :project_scope
OR (status = "' . self::STATUS_AWAITING_VERIFICATION . '"
AND id IN (SELECT item_id FROM bugtracker_item_affects
WHERE project_slug = :project_scope)))';
$params[':project_scope'] = $affectedFor;
WHERE project_slug = :project_scope_affects)))';
$params[':project_scope'] = $affectedFor;
$params[':project_scope_affects'] = $affectedFor;
// Die einfache Gleichheit weiter unten wuerde die Oeffnung sofort
// wieder zunageln.
+23 -3
View File
@@ -87,7 +87,8 @@ final class MonitorRepo
?string $groupKey = null,
?string $os = null,
$checks = null,
?string $appVersion = null
?string $appVersion = null,
?string $projectSlug = null
): array {
$metricsJson = (is_array($metrics) || is_object($metrics))
? json_encode($metrics, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE)
@@ -140,11 +141,11 @@ final class MonitorRepo
INSERT INTO watchdog_monitors (
source, instance, type, state, last_state_change_utc, expected_interval_sec,
last_seen_utc, last_status, last_message, metrics_json, health_json,
failing_checks, group_key, os, app_version, created_utc, updated_utc
failing_checks, group_key, os, app_version, project_slug, created_utc, updated_utc
) VALUES (
:source, :instance, :type, :state, UTC_TIMESTAMP(), :interval,
UTC_TIMESTAMP(), :last_status, :message, :metrics, :health,
:failing, :group_key, :os, :app_version, UTC_TIMESTAMP(), UTC_TIMESTAMP()
:failing, :group_key, :os, :app_version, :project_slug, UTC_TIMESTAMP(), UTC_TIMESTAMP()
)
ON DUPLICATE KEY UPDATE
-- Reihenfolge ist relevant: MySQL wertet die Zuweisungen von
@@ -165,6 +166,11 @@ final class MonitorRepo
-- COALESCE, damit ein Agent, der die Version nicht mitschickt,
-- eine frueher gemeldete nicht loescht.
app_version = COALESCE(VALUES(app_version), app_version),
-- Ebenso das Projekt: Ein Ping mit einem ungebundenen Token
-- (etwa ueber den Shared Key oder ein Alt-Token aus
-- watchdog_agent_tokens) darf eine bekannte Zuordnung nicht
-- wieder loeschen. Zuordnen kann nur, wer sie kennt.
project_slug = COALESCE(VALUES(project_slug), project_slug),
updated_utc = VALUES(updated_utc)
');
@@ -182,6 +188,20 @@ final class MonitorRepo
':group_key' => $groupKey,
':os' => $os,
':app_version' => $appVersion !== null ? mb_substr($appVersion, 0, 64) : null,
// Zu welchem Projekt gehoert dieser Monitor?
//
// Die Spalte gibt es seit Migration 014, geschrieben hat sie hier
// nie jemand. Ein Heartbeat legte den Monitor also mit
// project_slug NULL an, und jeder daraus abgeleitete Befund fiel
// auf das Scheinprojekt "default" zurueck (FindingRepo). Wirkung:
// dc_findings(project_slug="ibkrtrader") lieferte null Befunde,
// waehrend ein deviation.self-Befund mit elf Vorkommnissen
// bereitstand - nur unter einem Projekt, das es nicht gibt.
//
// Die Zuordnung war die ganze Zeit bekannt: Das Ping-Token ist an
// ein Projekt gebunden, und authorizeSource() liest die Bindung
// ohnehin. Sie wurde nur nicht weitergereicht. (#404)
':project_slug' => $projectSlug !== null ? mb_substr($projectSlug, 0, 64) : null,
]);
$monitor = $this->getMonitor($source, $instance);