[Entity-Service] Use staging's column names in the instance and deployed-product queries

[Rashmika998]

Summary

Three instance endpoints fail on staging today:

count instances: ERROR: column dn.deployment_ref does not exist (SQLSTATE 42703)

(SearchInstances, SearchInstanceMetrics, SearchInstanceUsage.) Staging's schema is built by the sync service, which renamed columns these queries were written against. Found while auditing table and column names against the live database.

Was (migration 000054)	Staging
deployment_node.deployment_ref	deployment_number
deployment_node.subscription_key	project_key
deployment_information.number_of_cores (text)	core_count (integer)
deployment_information.reported_created_on / reported_updated_on	payload_created_on / payload_updated_on

The deployment rename is a change of meaning, not just spelling. The value is a deployment number (DEP000002442), never a UUID, so the old join (cast deployment_ref to a UUID and match deployment.id) could not match anything, and its own comment said it was unverified against real data.

The join

• Project: project_key -> project.key (unique, present on every node), so a node's project no longer depends on its deployment resolving.
• Deployment: deployment_number -> deployment.number (unique) only if that deployment belongs to the node's own project. This guard matters: staging has three nodes whose deployment_number is "320", which equals the number of a deployment in a different project. Matching the number alone would have attached them to the wrong project. With the guard they stay unresolved (deployment nil, project still set).
• core_count is a real integer column, so the free-text parseCoreCount is removed.
• deployed_product_repo.go's node resolution uses the same rule.

Verification (against staging, throwaway tests, not committed)

• Every instance method (SearchInstances, SearchInstanceMetrics, SearchInstanceUsage, both stats methods) and SearchDeployedProducts, SearchDeployedProductMetrics, SearchDeployedProductUsageCounts now run without error.
• 16 nodes: 14 resolve to a project and 11 to a deployment, each equal to independent SQL, and none resolves to a deployment of another project. Filtering by project (12) and by deployment (9) equals the SQL counts. A deployed product resolves to 4 nodes, equal to SQL.
• gofmt, go vet, gosec (0 issues), govulncheck clean. go test has one failure, TestSNCaseService_CreateCase_PublishesCaseCreated, which fails the same way without this change.

Data gap, not a code bug

No deployment_information.node_id matches any deployment_node.node_id in staging (the former are sys_ids and TEST2 / TEST3), so no instance has metadata there.

Note

migrations/000054 still uses the old column names; staging does not match migrations/ (see the schema drift notes in #1876). This PR follows the live database, as asked.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

Next included review available in 16 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: wso2-open-operations/cs-tools/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 11f5558c-0b51-4ebc-9fc0-3913ac58483e

📥 Commits

Reviewing files that changed from the base of the PR and between d827781 and c1b7948.

📒 Files selected for processing (3)

• entity-service/CLAUDE.md
• entity-service/internal/repository/deployed_product_repo.go
• entity-service/internal/repository/instance_repo.go

---

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.}