chore: remove stale issue-tracker references from comments

Drop dangling #NNN issue-number citations across code and test
comments; the surrounding prose already explains the rationale
without them.

Author: farhan-syah

nodedb-sql/src/error.rs

@@ -74,9 +74,8 @@ pub enum SqlError {
     /// A positional `INSERT`/`UPSERT` `VALUES` row (no explicit column
     /// list) supplied more values than the target collection has declared
     /// columns. Binding the overflow value(s) to a synthetic `col{N}` name
-    /// would silently store them under an unaddressable column — the same
-    /// failure mode as #202 — so this is rejected rather than guessed
-    /// at.
+    /// would silently store them under an unaddressable column, so this is
+    /// rejected rather than guessed at.
     #[error(
         "INSERT/UPSERT into '{collection}': row has {given} value(s) but only \
          {declared} column(s) are declared; supply an explicit column list \

nodedb-sql/src/planner/dml.rs

@@ -142,8 +142,8 @@ pub fn plan_insert(ins: &ast::Insert, catalog: &dyn SqlCatalog) -> Result<Vec<Sq
     }
 
     // Positional INSERT (no column list): bind values to the collection's
-    // declared column order so named projections/predicates can find them
-    // (#202). No-op for named inserts and schemaless collections.
+    // declared column order so named projections/predicates can find them.
+    // No-op for named inserts and schemaless collections.
     let columns = resolve_insert_columns(columns, &info, rows_ast)?;
 
     // Vector-primary collection: bypass document encoding.
@@ -228,7 +228,7 @@ pub fn plan_upsert(ins: &ast::Insert, catalog: &dyn SqlCatalog) -> Result<Vec<Sq
     }
 
     // Positional UPSERT (no column list): bind to the collection's declared
-    // column order — see `plan_insert` for the full rationale (#202).
+    // column order — see `plan_insert` for the full rationale.
     let columns = resolve_insert_columns(columns, &info, rows_ast)?;
 
     let mut rows = convert_value_rows(&columns, rows_ast)?;
@@ -306,7 +306,7 @@ fn plan_upsert_with_on_conflict(
     }
 
     // Positional UPSERT (no column list): bind to the collection's declared
-    // column order — see `plan_insert` for the full rationale (#202).
+    // column order — see `plan_insert` for the full rationale.
     let columns = resolve_insert_columns(columns, &info, rows_ast)?;
 
     let mut rows = convert_value_rows(&columns, rows_ast)?;

nodedb-sql/src/planner/dml_helpers/insert_columns.rs

@@ -14,7 +14,7 @@ use crate::types::*;
 /// column names. Left alone, `convert_value_rows` falls back to synthetic
 /// `col0`, `col1`, ... names for every value (see its `col{i}` fallback
 /// below): the row stores fine, but named projections and WHERE predicates
-/// can never find it again (#202).
+/// can never find it again.
 ///
 /// Named inserts (`columns` already non-empty) and schemaless collections
 /// (`info.columns` empty — there is no declared order to bind to) pass

nodedb-sql/tests/ddl_constraint_rejection.rs

@@ -222,7 +222,7 @@ fn not_null_and_default_accepted() {
     }
 }
 
-// ── ENGINE = <name> trailing suffix (E1/#157 regression) ─────────────────────
+// ── ENGINE = <name> trailing suffix (E1 regression) ──────────────────────────
 //
 // A MySQL-style trailing `ENGINE = <name>` (or `ENGINE=<name>`) after the
 // column list must feed the same `engine` field as `WITH (engine='<name>')`,

nodedb-sql/tests/positional_insert_column_binding.rs

@@ -4,7 +4,7 @@
 //! explicit column list) must bind each value to the collection's
 //! DECLARED column names, not synthetic `col0`, `col1`, ... placeholders.
 //!
-//! The defect (#202): `INSERT INTO probe VALUES (42, 'stored?')` on
+//! The defect: `INSERT INTO probe VALUES (42, 'stored?')` on
 //! `probe (id INT PRIMARY KEY, note TEXT)` stored the row under `col0`/
 //! `col1` instead of `id`/`note`. `SELECT *` still looked correct (it
 //! doesn't care about names), but any named projection or `WHERE`
@@ -121,7 +121,7 @@ fn insert_rows(plan: SqlPlan) -> Vec<Vec<(String, SqlValue)>> {
     }
 }
 
-/// The core regression (#202): a positional INSERT must bind its
+/// The core regression: a positional INSERT must bind its
 /// values to the DECLARED column names, not `col0`/`col1`.
 #[test]
 fn positional_insert_binds_declared_column_names() {

nodedb-types/src/columnar/column_parse.rs

@@ -122,8 +122,8 @@ impl FromStr for ColumnType {
 
         match upper.as_str() {
             // `INT4`/`INT8`/`SMALLINT`/`INT2` are PostgreSQL wire-width integer
-            // keywords (issue #223: strict/kv `CREATE COLLECTION` rejected
-            // them as unknown types even though they're valid aliases). They
+            // keywords: strict/kv `CREATE COLLECTION` used to reject
+            // them as unknown types even though they're valid aliases. They
             // all collapse to the same `Int64` storage variant as
             // `BIGINT`/`INTEGER`/`INT` — nodedb always stores integers as a
             // full i64. The declared width is carried separately as an
@@ -134,7 +134,7 @@ impl FromStr for ColumnType {
             }
             // `FLOAT4`/`FLOAT8`/`FLOAT32`/`DOUBLE PRECISION` are PostgreSQL
             // wire-width float keywords, rejected as unknown types here for
-            // the same reason `INT4` was (issue #223). They all collapse to
+            // the same reason `INT4` was. They all collapse to
             // the same `Float64` storage variant as `DOUBLE`/`REAL`/`FLOAT` —
             // nodedb always stores floats as a full f64. The declared width is
             // carried separately as a [`super::FloatWidth`], which narrows the

nodedb-types/src/columnar/column_type.rs

@@ -286,9 +286,9 @@ mod tests {
         assert_eq!("UUID".parse::<ColumnType>().unwrap(), ColumnType::Uuid);
     }
 
-    /// `INT4`/`INT8`/`SMALLINT`/`INT2` are wire-width DDL keywords (issue
-    /// #223: strict/kv `CREATE COLLECTION` rejected them as unknown column
-    /// types even though they're valid PostgreSQL integer aliases). They all
+    /// `INT4`/`INT8`/`SMALLINT`/`INT2` are wire-width DDL keywords: strict/kv
+    /// `CREATE COLLECTION` used to reject them as unknown column
+    /// types even though they're valid PostgreSQL integer aliases. They all
     /// map to the same `Int64` storage variant as `BIGINT`/`INTEGER`/`INT` —
     /// nodedb's columnar/strict/kv storage always keeps integers as a full
     /// i64; only the wire (`DdlColType`) layer narrows the advertised OID.

nodedb/src/control/gateway/router.rs

@@ -66,7 +66,7 @@ pub fn route_plan(
     // Commit-time meta-ops (ResolveTxn / TransactionBatch) carry no collection
     // name, so their vShard cannot be derived here — the primary_vshard
     // fallback would silently send them to vShard 0 and durably apply the
-    // commit batch on the wrong core (#193). They are dispatched with the
+    // commit batch on the wrong core. They are dispatched with the
     // task's pre-classified `vshard_id` (see `dispatch_single_shard`), never
     // through the gateway.
     {
@@ -463,7 +463,7 @@ mod tests {
 
     /// Commit-time meta-ops carry no collection name, so the router cannot
     /// derive their vShard — silently falling back to vShard 0 durably applies
-    /// the commit batch on the wrong core (#193). They must be rejected here;
+    /// the commit batch on the wrong core. They must be rejected here;
     /// callers dispatch them with the task's pre-classified `vshard_id`.
     #[test]
     fn commit_meta_ops_are_rejected() {

nodedb/src/control/planner/catalog_adapter/type_convert.rs

@@ -250,7 +250,7 @@ fn parse_type_str(s: &str) -> SqlDataType {
         // Every spelling `IntWidth::from_declared_type` recognizes must appear
         // here too, or the column resolves to the `_ => String` default and
         // advertises OID 25 (text) — the exact failure that made `SMALLINT`
-        // columns unreadable (issue #217). `parse_type_str` decides *whether*
+        // columns unreadable. `parse_type_str` decides *whether*
         // the column is an integer; `IntWidth` decides *how wide*.
         "INT" | "INTEGER" | "INT4" | "INT8" | "INT64" | "BIGINT" | "SMALLINT" | "INT2" => {
             SqlDataType::Int64
@@ -276,7 +276,7 @@ mod tests {
     use crate::control::security::catalog::StoredCollection;
 
     /// `SMALLINT`/`INT2` are valid PostgreSQL wire-width integer keywords
-    /// (issue #217) that must resolve to the same `SqlDataType::Int64` arm as
+    /// that must resolve to the same `SqlDataType::Int64` arm as
     /// `INT`/`INTEGER`/`INT4`/`INT8`/`BIGINT` — previously they were unlisted
     /// and fell through to the `_ => SqlDataType::String` default, which is
     /// what produced the wire OID 25 (text) bug for `SMALLINT` columns.

nodedb/src/control/server/native/dispatch/transaction.rs

@@ -34,7 +34,7 @@ use super::DispatchCtx;
 /// The gateway must NOT be used here: commit-time tasks carry `MetaOp` plans
 /// (`ResolveTxn`, `TransactionBatch`) with no named collection, so the
 /// gateway's router cannot derive a route for them and falls back to
-/// vShard 0 — durably applying the commit batch on the wrong core (#193).
+/// vShard 0 — durably applying the commit batch on the wrong core.
 pub(crate) struct NativeTxnDp<'a> {
     pub(crate) state: &'a SharedState,
 }