Golang Microservices Full Course #09 - Code Review & Bug Fixing

Main ideas & lessons conveyed

• The episode focuses on code review and bug fixing for a Go (Golang) microservices / microservices-like wallet/transaction system, continuing from a previous episode about optimistic locking.
• Multiple issues are identified and corrected across:
  • JSON struct tags / struct definitions (using the correct json:"..." format and separators).
  • Repository/query handling (avoiding dead code and ensuring correct behavior when values are null/empty).
  • Timestamp handling after optimistic lock updates (ensuring created_at / updated_at behavior aligns with DB defaults).
  • HTTP handler/controller implementation for transaction endpoints, including middleware-based authorization and request validation.
  • API routing wiring (ensuring the correct handler is attached to the correct route).

Methodology / step-by-step actions shown

A) Bug fix: incorrect JSON/tag syntax in Go models

1. Review transaction-related model files in the transaction folder (e.g., tx.go and related domain files).
2. Identify struct tag syntax that uses an incorrect separator/pattern.
3. Replace it with the correct Go JSON tag syntax:
   • Use json:"fieldName" instead of the wrong form.
4. Apply the fix consistently across all affected occurrences (the speaker checks multiple lines/files).

B) Bug fix: repository/query null handling (sender wallet ID)

1. Locate the repository file responsible for “get by id…” / scanning logic.
2. Observe that the sender is “not filled” by the scan function.
3. Identify a conditional guard that becomes dead code because the sender validity condition can’t be met.
4. Update logic so that if the sender wallet ID is null:
   • The code should not silently continue.
   • The function should panic or return an error, since a null sender wallet ID is invalid for the intended flow.

C) Bug fix: optimistic lock / timestamp mismatch

1. After optimistic lock updates in the transfer service, notice the sender wallet timestamp (or last-updated field) still shows the prior value.
2. Check whether the database schema already defines default/current timestamp behavior.
   • If the DB uses default current_timestamp (or equivalent), then manual timestamp overrides may be unnecessary.
3. Remove redundant manual timestamp update code or change it to rely on DB defaults / consistent now handling.
   • The speaker suggests deleting redundant timestamp overrides or adjusting based on the DB migration.

D) Implement missing transaction handler / controller

1. Create or locate the handler package and implement a TransactionHandler that depends on transaction-related services.
2. Ensure handler wiring references the correct service type (not accidentally mixing ledger service vs transaction service).
3. Implement the endpoint handler function (the “transaction transfer handler” flow), including:
   • Extract user_id from middleware claims (JWT claims are referenced).
   • If user_id is missing:
     • Return a custom error with:
       • HTTP status: 401 Unauthorized
       • Message: “user context not found”
   • Bind request body into a request struct (including validation and binding).
   • Call the service method (e.g., svc.Transfer(...)) with:
     • request context
     • sender user id (string)
     • transaction transfer request model
   • If service returns an error:
     • Return an error JSON response with the appropriate HTTP status and message.
   • If successful:
     • Return a success response message such as “transaction successful”.

E) Route registration / main wiring

1. Edit main.go (or routing setup).
2. Wire the transaction transfer route to the correct handler function.
3. Ensure the route method is correct.
   • The speaker mentions fixing a routing/handler mismatch (e.g., issues related to reflection/signature compatibility).
4. Confirm request validation rules are correctly formatted:
   • Remove spaces after commas in validation rules (a,b instead of a, b).
5. Ensure JSON/field tags and validation expectations match what the request body actually provides.

F) Verify with local testing (Docker + Postman)

1. Start the app using:
   • go run cmd/main.go
2. Use Postman to test:
   • Register/login to obtain an access token for the sender user.
   • Send a POST request to the transaction transfer endpoint.
   • Include fields such as:
     • receiver email
     • amount (e.g., 50,000, later increased to 100 for balance testing)
     • description
     • item potency key / potency key (example key mentioned: test transfer 001)
3. Test failure cases:
   • “transfer missing token” → confirms auth token requirement.
   • “receiver email … filter doesn’t … receiver email” (likely validation/search mismatch).
   • “insufficient balance” for the sender wallet.
4. Fix and retest:
   • Temporarily adjust sender balance (the speaker increases/update it so the transfer can succeed).
   • Confirm:
     • response includes updated balances
     • transaction success message is returned
     • DB/ledger entries reflect correct debit/credit and transaction ID
       • ledger rows should reference sender/receiver wallet IDs and associate them with the transaction.

G) Top-up handling plan (not fully implemented yet)

• The episode discusses adding top up capability but notes it’s not fully implemented in the API/service yet.
• Current approach:
  • Create/branch work for bug fixing and review (e.g., feature/009-bugfixing).
  • For testing, directly inject/update balances in the database (manual updates).
• Future plan:
  • Real top up requires payment integration and virtual bank/account logic.
  • Add provider validation first, then credit the e-wallet.

H) Git workflow reminder (course practice)

• Normally:
  1. Push to a feature branch
  2. Open/merge via pull request to master
  3. Pull updates before continuing development
• For tutorial purposes, the speaker may simplify by pushing directly to master.

Speakers / sources featured

• Primary speaker: Unnamed course instructor (guides coding/testing workflow throughout).
• Other sources/guests: None explicitly named.