Repos / phenix-destination-search

phenix-destination-search

Destination search for Phenix: a containerised .NET 6 API querying an AWS OpenSearch destinations index, alongside a legacy .NET Framework 4.7.2 WebApi and SQL search database it is meant to replace.

35 · redmediumloosely attachedAWSZDD: not applicableapidormantsecrets in source

Health score

0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.

Runtime currency / 25

.NET Framework, out of mainstream support

Legacy transport / 15

No legacy WCF or SOAP surface

Test posture / 15

Some tests, coverage is thin

Security hygiene / 15

Credentials or keys committed to source

Dangerous coupling / 15

shares a core database (sqlserver:Phenix)

Activity / 10

Dormant: no meaningful change for two years or more while still deployed

Deployment hygiene / 5

CI in place

Health over time

Baseline 35 recorded 2026-07-27. The trend fills in with each monthly assessment run.

Facts

Languages	csharp
Frameworks	ASP.NET Core 6, MediatR, NEST, ASP.NET Core 2.2, Entity Framework 6
Runtimes	.NET 6, .NET Framework 4.7.2
Tests / CI	some / CI in place
Last commit	2024-11-19
Owner	Owner unknown (mapping to be curated)
Domain	Content and destinations (system generated; curate in repo-owners.json to override)
Product area	Phenix
Hosted	AWS Deployed to AWS build "phenix-destination-search-api" (build-destination-search-api.yml): AWS signal "containerAfterBuild with awsRegion (image pushed to ECR)"
Releases	0 release pipeline(s):
Integration	rest
Source	Open in Azure DevOps

Risk flags

plaintext-credentials eol-runtime legacy-framework dormant boilerplate-readme shared-db incomplete-migration

Each flag links to its glossary definition.

Dependencies in context

View in full graph

Laying out the graph…

greenamberreddata store (square, dashed link)Node size follows fan-in. Click any node to open it.

Entanglement

loosely attached Bound into the core by 1 mechanism(s).

Shares core database sqlserver:Phenix

Detaches when the shared database group it belongs to gains an owned API or completes schema separation (sqlserver:Phenix).

Depends on / used by

Depends on (3)

tc-connectionbroker

tc-api-tools

tc-diagnostics-portal

Used by (0)

No internal dependents.

Data stores

opensearch:destinations sqlserver:DestinationSearch sqlserver:Phenix mongodb:DestinationSearch_logs

Migration playbooks

Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.

ZDD adoption

Not applicable

Not a deployed service (libraries, database definitions, desktop apps) or a retirement candidate not worth the investment. Retirement or consolidation candidate; do not invest in ZDD adoption.

SQL Server exit

Retire instead

This repo is a retirement or consolidation candidate. Do not invest in a database migration; execute the retirement and the SQL Server dependency disappears with it.

Containerisation

Retire instead

This repo is a retirement or consolidation candidate; containerising it would be investment in something we intend to switch off.

Recommended actions

Rotate credentialsStage 0: rotate exposed credentials

Rotate the credentials committed to phenix-destination-search

Risk flags indicate credentials or keys in source (plaintext-credentials). Rotate now and enable secret scanning in CI; this is independent of all other work.

Impact: Closes a live security exposure at near-zero cost

proposed

RetireStage 1: shrink the estate

Review phenix-destination-search for retirement

Dormant (last commit 2024-11-19) yet still release-linked, and nothing depends on it. Confirm remaining use, then retire and disarm its pipeline.

Impact: Shrinks the estate before the expensive work begins

proposed

Assessment notes

phenix-destination-search

Purpose

Destination search behind Phenix selling journeys. The repo holds two generations: the new DestinationSearch.Api (.NET 6, MediatR use-cases, Lucene.Net helpers) that searches a destinations index in AWS OpenSearch via the NEST client, and the legacy DestinationSearch.WebApi (.NET Framework 4.7.2 hosting ASP.NET Core 2.2) backed by a DestinationSearch SQL database with spatial types, unigram/bigram keyword tables and EF6.

Tech stack

Three solutions: the new API (net6.0, FluentValidation, AutoMapper, Swashbuckle, TC health checks), the legacy WebApi (net472/win7-x86, EF6, Microsoft.SqlServer.Types, PhenixAuthLib, TravelCounsellors.ApiTools, ConnectionBroker) with a published TC.DestinationSearch.Client contract package, and a DestinationSearch.Database change-script project. StyleCop and Nerdbank-style version.json at the root.

Deployment

Included via build->yaml-deploy with 0 classic releases: active build pipeline phenix-destination-search-api from build-destination-search-api.yml, using shared InternalOSS templates with containerAfterBuild: true into the ds container namespace (eu-west-1). Three further YAML files (db, web-api, web-api-client) plus on-prem IIS PowerShell scripts under deployment/ cover the legacy path but have no traced pipelines.

Dependencies

Internal: TC.ConnectionBroker.* (tc-connectionbroker) for SQL/endpoint resolution in the legacy stack, TravelCounsellors.ApiTools (tc-api-tools), TC.Diagnostics.HealthChecks (tc-diagnostics-portal). External: AWS OpenSearch (VPC endpoints in config), New Relic APM.

Data stores

OpenSearch destinations index (new API); SQL Server DestinationSearch database (legacy — Destinations, ExtendedKeywords, SearchBigrams/Unigrams, ProviderSearchData, with change scripts that join across to the shared Phenix database); MongoDB DestinationSearch_logs for legacy request logging.

Integration points

Inbound REST only (versioned, Swagger, PhenixAuth on the legacy WebApi). No messaging, WCF or streams.

Code health

Four test projects but only ~13 test files, so coverage is thin. The README is untouched Azure DevOps boilerplate. No commits since 2024-11-19 — dormant for ~20 months. Most significantly, OpenSearch usernames and passwords for QA and production are committed in plaintext in appsettings.json / appsettings.production.json.

Modernisation risks

Medium. The deployed container API is .NET 6 (now end-of-support) and needs a straightforward bump, but the real issues are the plaintext production search credentials in source (rotate and move to a secret store), the half-finished migration leaving a net472/EF6/SQL legacy stack and its client package in-tree, and dormancy — nobody has touched this in a long time while it presumably still serves search traffic.