[Bug][Blueprint] Cron-triggered pipelines use a sanitized plan after PATCH /blueprints, gitextractor fails with masked credentials
メンテナーはふだん 3 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Read backend/server/services/blueprint.go around PatchBlueprint, saveBlueprint, and reloadBlueprint, then inspect SanitizeBlueprint and pluginOptionSanitizers in backend/server/services/pipeline.go. Trace how the cron job and API response share the blueprint plan, then review existing blueprint service tests. Done means cron runs after a PATCH use the stored credentials while the API response still masks them.
索引モデルが issue の本文から書いたものです。
説明
Search before asking
- I had searched in the issues and found no similar issues.
What happened
After updating an advanced-mode blueprint through the API (PATCH /blueprints/:id), the next pipeline started by the cron schedule runs with a sanitized (masked) plan. Every gitextractor task fails with:
subtask Clone Git Repo ended unexpectedly
git cmd [git clone https://git:*****@<gitlab-host>/<group>/<repo>.git /tmp/gitextractorXXXX --bare] failed
remote: HTTP Basic: Access denied. ...
The token stored in the database is correct:
- Triggering the same blueprint manually (
POST /blueprints/:id/trigger) clones every repo fine. - After a
lakerestart, cron runs work again until the next PATCH.
In our case it was 1330/1330 gitextractor tasks failing in a cron run, while the same repos cloned fine in a manual run of the same plan a few hours earlier.
Root cause (v1.0.3-beta15, still present on main):
PatchBlueprint→saveBlueprint→reloadBlueprint(blueprint)registers the cron job with the same pointer:
cronManager.AddJob(blueprint.CronConfig, &BlueprintJob{blueprint})(backend/server/services/blueprint.go).- Right after saving,
PatchBlueprintcallsSanitizeBlueprint(blueprint)on that same object to build the API response. - The
gitextractorsanitizer (pluginOptionSanitizersinbackend/server/services/pipeline.go) replaces the password inoptions["url"]with*in place. - When the cron fires,
BlueprintJob.Run()callscreatePipelineByBlueprint(bj.Blueprint, ...), which for advanced mode usesblueprint.Planas is. The new pipeline gets the masked URL.
TriggerBlueprint and ReloadBlueprints (at startup) load the blueprint from the DB, which is why manual runs and runs after a restart are fine. Normal-mode blueprints are not affected, because their plan is regenerated from the connections on each run.
What do you expect to happen
Cron-triggered pipelines should use the stored (unsanitized) plan, the same as manual triggers. Sanitizing the API response should not change the object the scheduler holds.
How to reproduce
- Create an advanced-mode blueprint with a
gitextractortask whoseurlcontains credentials (https://git:<token>@host/group/repo.git), withenable: true,isManual: falseand a cron, e.g.*/5 * * * *. - Update it through the API, e.g.
PATCH /blueprints/:idwith{"cronConfig": "*/5 * * * *"}or with a newplan. - Wait for the cron to fire.
- The
gitextractortask fails withHTTP Basic: Access denied, and the pipeline's task options show the masked URL. - Trigger the same blueprint with
POST /blueprints/:id/trigger: it succeeds.
Anything else
Possible fixes, either of:
- In
BlueprintJob.Run(), reload the blueprint from the DB by id before creating the pipeline. - In
PatchBlueprint(and other handlers that sanitize aftersaveBlueprint), sanitize a deep copy rather than the object passed toreloadBlueprint.SanitizeBlueprintwrites intoblueprint.Plan[i][j], and the option maps are shared.
Workaround: set the blueprint to manual and trigger it from an external scheduler with POST /blueprints/:id/trigger, or restart lake after every blueprint update.
Version
v1.0.3-beta15 (helm chart 1.0.3-beta15). Code verified unchanged on main.
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
- 主要言語
- Go
- スター
- 3.2k
- フォーク
- 824
- 平均マージ
- 2日 22時間
- マージ済み PR（30日）
- 46
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/devlake のほかの issue
-
[Bug][SonarQube] Migration 20230927145127 is not re-runnable: fails with "constraint _tool_sonarqube_file_metrics_pkey does not exist" after an interrupted run対応中かも @chenwei791129 が今日担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
メンテナーはふだん 3 日以内に返信
-
type/bug
難易度 3/5 1〜2日 初心者へのやさしさ 64/100
メンテナーはふだん 3 日以内に返信
-
[Bug][Blueprint] Scheduled run fails silently when plan generation errors対応中かも @jcamargos が 2 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
メンテナーはふだん 3 日以内に返信
-
難易度 3/5 半日 初心者へのやさしさ 62/100
メンテナーはふだん 3 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 42/100
メンテナーはふだん 3 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 2 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
devlikeapro/waha#2322 ·
メンテナーはふだん 2 日以内に返信