chore: add namespaced id or key

[turip]

Overview

Useful at places where we don't know yet if something is an ID or a key.

Summary by CodeRabbit

• Chores
  • Added internal validation infrastructure for handling namespaced identifiers with improved error reporting.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR introduces a new NamespacedIDOrKey struct in the models package with two string fields (Namespace and IDOrKey) and a Validate() method that checks for the presence of both fields and returns combined errors using errors.Join.

Changes

Cohort / File(s)	Summary
New Model Type pkg/models/idorkey.go	Adds NamespacedIDOrKey struct with Namespace and IDOrKey fields, including JSON tags and a Validate() error method for field validation

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

This is a straightforward addition of a simple data model with basic validation logic. The implementation is clean and follows standard Go patterns for error handling.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: adding a new NamespacedIDOrKey type to the models package.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/add-namespaced-id-or-key

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

pkg/models/idorkey.go (1)

15-26: Consider aligning with the existing generic validation error helper

The validation logic itself is solid: both fields are checked and aggregated with errors.Join, and you get nil when everything’s OK.

If you want error handling to feel consistent with Validate[T] in pkg/models/validator.go (which wraps in NewNillableGenericValidationError), you could have this method return the same wrapped error type instead of a plain joined error, e.g.:

-	return errors.Join(errs...)
+	return NewNillableGenericValidationError(errors.Join(errs...))

That way callers don’t have to special‑case this type vs. anything validated through the generic helper.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 12d29e7 and 35fa15c.

📒 Files selected for processing (1)

• pkg/models/idorkey.go (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.go

⚙️ CodeRabbit configuration file

**/*.go: In general when reviewing the Golang code make readability and maintainability a priority, even potentially suggest restructuring the code to improve them.

Performance should be a priority in critical code paths. Anything related to event ingestion, message processing, database operations (regardless of database) should be vetted for potential performance bottlenecks.

Files:

• pkg/models/idorkey.go

🧬 Code graph analysis (1)

pkg/models/idorkey.go (3)

app/common/namespace.go (1)

• Namespace (13-15)

pkg/ref/ref.go (1)

• IDOrKey (9-12)

pkg/models/validator.go (1)

• Validate (16-26)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)

• GitHub Check: Artifacts / Container image
• GitHub Check: Migration Checks
• GitHub Check: Code Generators
• GitHub Check: Test
• GitHub Check: Build
• GitHub Check: Lint
• GitHub Check: Analyze (go)

🔇 Additional comments (1)

pkg/models/idorkey.go (1)

8-13: Clear, focused modeling of the “ID or key” case

This type and its doc comment nicely capture the “we don’t yet know if it’s an ID or key” scenario, and the JSON shape (namespace, idOrKey) is straightforward for API consumers. Looks good to me as-is.