Chore/bazel build fixes core elx #2674
No reviewers
Labels
No labels
1week
2weeks
Failed compliance check
IP cameras
NATS
Possible security concern
Review effort 1/5
Review effort 2/5
Review effort 3/5
Review effort 4/5
Review effort 5/5
UI
aardvark
accessibility
amd64
api
arm64
auth
back-end
bgp
blog
bug
build
checkers
ci-cd
cleanup
cnpg
codex
core
dependencies
device-management
documentation
duplicate
dusk
ebpf
enhancement
eta 1d
eta 1hr
eta 3d
eta 3hr
feature
fieldsurvey
github_actions
go
good first issue
help wanted
invalid
javascript
k8s
log-collector
mapper
mtr
needs-triage
netflow
network-sweep
observability
oracle
otel
plug-in
proton
python
question
reddit
redhat
research
rperf
rperf-checker
rust
sdk
security
serviceradar-agent
serviceradar-agent-gateway
serviceradar-web
serviceradar-web-ng
siem
snmp
sysmon
topology
ubiquiti
wasm
wontfix
zen-engine
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
carverauto/serviceradar!2674
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refs/pull/2674/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Imported from GitHub pull request.
Original GitHub pull request: #2311
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/2311
Original created: 2026-01-15T03:51:53Z
Original updated: 2026-01-15T04:04:16Z
Original head: carverauto/serviceradar:chore/bazel_build_Fixes-core-elx
Original base: staging
Original merged: 2026-01-15T04:04:15Z by @mfreeman451
User description
IMPORTANT: Please sign the Developer Certificate of Origin
Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include
a DCO sign-off statement indicating the DCO acceptance in one commit message. Here
is an example DCO Signed-off-by line in a commit message:
Describe your changes
Issue ticket number and link
Code checklist before requesting a review
PR Type
Bug fix, Enhancement
Description
Create tenant membership automatically for newly registered users
Fix tenant schema configuration in Ash resources
Improve magic link email tenant resolution with fallback logic
Remove unused Bazel dependencies and npm configuration
Add idempotent migration guards for SNMP profiles
Diagram Walkthrough
File Walkthrough
3 files
New module for automatic tenant membership creationIntegrate CreateTenantMembership into user creation actionsImprove active tenant resolution and add tenant fetching7 files
Improve tenant resolution with multiple fallback strategiesAdd explicit public schema configurationAdd explicit public schema configurationAdd explicit public schema configurationAdd explicit public schema configurationAdd explicit public schema configurationAdd idempotent guards to migration operations3 files
Remove unused Go and npm dependenciesAdd snmp_service.go to build sourcesRemove unused backoff dependencyImported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2311#issuecomment-3752793875
Original created: 2026-01-15T03:52:38Z
PR Compliance Guide 🔍
Below is a summary of compliance checks for this PR:
Privilege escalation
Description: The user registration actions accept the
:roleattribute and the newCreateTenantMembershipchange grants:ownermembership whenuser.roleis:admin/:super_admin, which could enable a privilege escalation (self-assigning elevatedroles leading to tenant owner membership) if role assignment is not strictly constrained
by policy/changeset validation.
user.ex [97-126]
Referred Code
Authorization bypass
Description:
resolve_active_tenant/2can fall back tofetch_tenant_by_id/1using a caller-providedactive_tenant_ideven when the tenant is not present in the user's memberships, andfetch_tenant_by_id/1reads using a platform actor, which may allow cross-tenant dataexposure (e.g., retrieving another tenant’s
id/slug/name/is_platform_tenant) andpotentially improper tenant scoping if downstream logic trusts
active_tenant.scope.ex [121-147]
Referred Code
🎫 No ticket provided
Codebase context is not defined
Follow the guide to enable codebase context checks.
Generic: Meaningful Naming and Self-Documenting Code
Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting
Status: Passed
Generic: Security-First Input Validation and Data Handling
Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities
Status: Passed
Generic: Robust Error Handling and Edge Case Management
Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation
Status: 🏷️
Errors are swallowed: Membership creation failures are logged but always return
:ok, preventing callers fromdetecting or handling a partial failure (user created without membership).
Referred Code
Generic: Comprehensive Audit Trails
Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.
Status: 🏷️
Non-audit logging: Tenant membership creation (a permission-relevant action) is only written via
Loggerandnot clearly emitted to a dedicated/structured audit trail with consistent context and
outcome fields.
Referred Code
Generic: Secure Error Handling
Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.
Status: 🏷️
Potential user-facing raise: The sender raises
"Unable to resolve tenant for magic link URL", which maypropagate to user-facing surfaces depending on caller handling and could leak internal
routing details.
Referred Code
Generic: Secure Logging Practices
Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.
Status: 🏷️
Sensitive data in logs: Logging includes
user.id,tenant_id, andinspect(errors)/inspect(reason)which may containsensitive internal details or user data depending on Ash error contents.
Referred Code
Compliance status legend
🟢 - Fully Compliant🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label
Imported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2311#issuecomment-3752795573
Original created: 2026-01-15T03:53:43Z
PR Code Suggestions ✨
Explore these optional code suggestions:
✅
Use specific error types for checksSuggestion Impact:
The commit removed string-based matching in unique_constraint_error?/1 and switched to matching on a specific Ash error struct (Ash.Error.Changes.InvalidAttribute) and inspecting its private_vars for constraint_type: :unique, improving robustness. It did not implement the exact suggested structs (Ash.Error.Changes.Unique / AshPostgres.Error.DuplicateEntry) but follows the same intent.code diff:
Refactor
unique_constraint_error?/1to pattern match on specific Ash errorstructs instead of relying on string matching error messages for better
robustness.
elixir/serviceradar_core/lib/serviceradar/identity/changes/create_tenant_membership.ex [96-110]
[Suggestion processed]Suggestion importance[1-10]: 7
__
Why: The suggestion correctly identifies that string-matching on error messages is brittle. Using pattern matching on specific error types like
Ash.Error.Changes.Uniquemakes the code more robust and maintainable.✅
Prevent membership errors aborting flowSuggestion Impact:
The after_action now wraps create_membership_if_needed(user) in a try/rescue and logs unexpected exceptions, preventing them from bubbling up and failing the flow (logging uses Exception.message/1). The commit also includes additional refactoring of membership creation/error handling beyond the suggestion.code diff:
Wrap the
create_membership_if_neededcall in atry/rescueblock within theafter_actionto catch and log unexpected exceptions, preventing user creationfrom failing.
elixir/serviceradar_core/lib/serviceradar/identity/changes/create_tenant_membership.ex [26-29]
[Suggestion processed]Suggestion importance[1-10]: 6
__
Why: This is a good defensive programming suggestion. While the
create_membership_if_neededfunction already handles expected errors, atry/rescueblock would prevent any unexpected exceptions from crashing the user creation process, making it more resilient.