Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Resolve duplicate `AuditLog` entity — `src/common/database/entities/` and `src/infrastructure/audit/entities/` both define one

Open
  • Is something wrong?
#213 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
nodejs, typescript
Domain
backend, databases

Research direction

Start by checking which of the two audit-log.entity.ts files (src/common/database/entities/ and src/infrastructure/audit/entities/) is registered in the TypeORM forFeature calls and glob config in src/config/typeorm.config.ts, then diff their fields. Keep the one the running app uses, merge in any extra columns, and re-point imports; test/audit/provenance.e2e-spec.ts and the migrations under src/migrations/ must still pass. Done when only one AuditLog entity remains and the tests and migrations pass against a scratch database.

Written by the indexing model from the issue text.

Description

advanced help wanted refactor

Problem

There are two files named audit-log.entity.ts, defining what is almost certainly the same entity:

  • src/common/database/entities/audit-log.entity.ts
  • src/infrastructure/audit/entities/audit-log.entity.ts

This is a persistence-level hazard, not just tidiness. Both are TypeORM entities, so if both are registered in the same TypeOrmModule.forFeature() call or discovered by glob configuration, TypeORM will attempt to create or map the same table twice — which surfaces as a confusing duplicate-metadata error, or as two classes writing to one table with different field mappings.

The same duplicate-name pattern exists elsewhere (confirmed by scanning src/ for repeated filenames):

File Locations
audit-log.entity.ts src/common/database/entities/, src/infrastructure/audit/entities/
email.service.ts src/core/auth/, src/email/
kyc.guard.ts src/common/guard/, src/core/auth/
roles.decorator.ts src/common/decorators/, src/common/guard/
portfolio.module.ts src/portfolio/, src/investment/portfolio/

Why it matters

An audit log is the record the README calls out as central to "Observable & auditable" (line 32). Two definitions of it mean it is not clear which one is authoritative, which table is authoritative, or what the actual column set is. Anyone writing an audit query has to first work out which entity to import, and there is a real chance a migration written against one does not match the other.

Suggested Direction

  1. Determine which is registered. Check every TypeOrmModule.forFeature([...]) call and any glob-based entity discovery in src/config/typeorm.config.ts. Whichever entity the running app actually uses is the one to keep.
  2. Diff them field by field before choosing. If they have diverged, that is itself important — it may mean one is stale, or that columns exist in the database with no matching property. Compare against the real schema via npm run migration:generate in a scratch database.
  3. Keep one, delete the other, and re-point imports. Use npx tsc --noEmit to find every reference.
  4. Add a CI guard so this cannot recur. A short script in scripts/ that fails on duplicate entity filenames is cheap: 
    Get-ChildItem src -Recurse -Filter '*.entity.ts' | Group-Object Name | Where-Object Count -gt 1
    This is more targeted than the existing test:kyc-guard-scan, which covers guards only.
  5. Apply the same treatment to the other duplicates in the table, in separate PRs.

Constraints

  • Do not lose audit data. If the two entities have different columns, reconcile the wider schema and backfill rather than dropping fields.
  • Existing migration files under src/migrations/ must keep applying cleanly. Verify against a scratch database, not production.
  • There are audit-related tests: test/audit/provenance.e2e-spec.ts and src/infrastructure/audit/ services. They must pass unchanged.
  • src/common/database/entities/ versus src/infrastructure/audit/entities/ also raises the module-ownership question — see the src/common/ consolidation issue.

Acceptance Criteria

  • Exactly one AuditLog entity exists.
  • The surviving entity is the one the running app already uses.
  • Field-level differences are documented; the union of columns is preserved.
  • Migrations still apply cleanly against a scratch database.
  • A CI check fails on duplicate *.entity.ts filenames.
  • test/audit/provenance.e2e-spec.ts and npm test pass.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.