Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Org scoped searches disagree on what a deleted organization means

オープン
  • 何か問題がありますか？
#1,956 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
api, backend, database

調査の方向性

Trace the handlers and aggregate services for the invoice and token RPCs first to find where their 404 responses originate, then compare that path with the other org-scoped searches and OrganizationRepository.Delete. Make every listed search resolve the organization consistently and return 404 when absent while retaining the SQL live(organizations) checks; verify the behavior for all affected RPCs.

索引モデルが issue の本文から書いたものです。

説明

The problem

Asking an org scoped search about an organization that is gone gives different answers depending on which RPC you call. A client cannot tell "this organization does not exist" apart from "this organization has nothing to show".

We want 404 not found everywhere.

Where things stand today

Verified by reading the handlers and services:

RPC Today How
SearchOrganizationServiceUsers 404 The handler calls orgService.GetRaw first, which reads live rows only
SearchOrganizationUsers 200, empty list After #1953 the SQL filters the organization out
SearchOrganizationProjects 200, empty list After #1953 the SQL filters the organization out
SearchUserProjects 200, empty list After #1953 the SQL filters the organization out
SearchOrganizationPATs 200, with rows No check anywhere. See the comment on #1953
SearchOrganizationInvoices 404 Needs confirming, see below
SearchOrganizationTokens 404 Needs confirming, see below

The end to end run in #1952 reported 404 for invoices and tokens. But neither handler nor either aggregate service resolves the organization. So something upstream is doing it, and part of this work is finding out what. If it turns out to be a shared path, that path may be the right place to fix all of them at once.

What to do

  1. Find out where the 404 for invoices and tokens comes from.
  2. Pick one way for every org scoped search to resolve the organization before running the query, and answer 404 when it is not there. Reuse whatever invoices and tokens already go through if that turns out to be shared.
  3. Apply it to SearchOrganizationUsers, SearchOrganizationProjects, SearchUserProjects and SearchOrganizationPATs.
  4. Keep the SQL level live(organizations) checks from #1953 as well. They are cheap and they guard the case where a policy row outlives its organization. policies.resource_id has no foreign key to organizations, so a hard deleted organization does leave membership policies behind.

Why it matters

Today OrganizationRepository.Delete is a hard delete and nothing sets deleted_at on organizations, so the split is mostly invisible. It will stop being invisible the moment organizations get a soft delete. Better to settle it now while the blast radius is small.

Related

  • #1953 added the SQL level checks for three of these searches
  • #1952 changed how a bad organization id is reported, which is what surfaced the split
主要言語
Go
スター
344
フォーク
47
平均マージ
2日 20時間
マージ済み PR（30日）
39

環境構築

このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

raystack/frontier のほかの issue

raystack/frontier の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。