Skip to content

Add command location search fails due to API response format mismatch #61

@timothyfroehlich

Description

@timothyfroehlich

Problem

The command is failing to create database entries and trigger initial notifications due to a mismatch between the API response format expected by the code and the format returned by test fixtures.

Root Cause Analysis

Status Mismatch

The location search logic in checks for specific status values, but there's inconsistency between:

  • Production API: Returns statuses like , ,
  • Test fixtures: May return or other formats
  • Code expectations: Originally only checked for

API Processing vs Fixture Format

The function is designed to process raw API responses and return a structured format, but the test API mocker returns raw fixture data without this processing layer.

Evidence

Failing Tests

    • Location search not creating database entries
    • City search not working
    • City with radius search failing

Error Messages

Database entries are not being created at all, indicating the location search is failing before reaching the database insertion step.

Current Status

Partial Fix Applied

PR #58 includes improvements to status handling:

  • Enhanced to accept multiple status types (, , )
  • Improved robustness for different API response formats

Remaining Issues

  1. Test fixture format alignment: The mock API responses need to match what expects to return
  2. API processing layer: The test environment bypasses the API processing that happens in production
  3. Status standardization: Need consistent status handling across all search types

Reproduction Steps

  1. Run ============================= test session starts ==============================
    platform linux -- Python 3.13.5, pytest-8.4.1, pluggy-1.6.0 -- /home/linuxbrew/.linuxbrew/opt/python@3.13/bin/python3.13
    cachedir: .pytest_cache
    rootdir: /home/froeht/DisPinMap
    configfile: pytest.ini
    plugins: xdist-3.7.0, asyncio-1.0.0
    asyncio: mode=Mode.STRICT, asyncio_default_fixture_loop_scope=None, asyncio_default_test_loop_scope=function
    collecting ... collected 1 item

tests/integration/test_commands_e2e.py::test_add_location_by_name_e2e FAILED [100%]

=================================== FAILURES ===================================
________________________ test_add_location_by_name_e2e _________________________
tests/integration/test_commands_e2e.py:72: in test_add_location_by_name_e2e
assert mock_notifier.send_initial_notifications.called
E AssertionError: assert False
E + where False = .called
E + where = .send_initial_notifications
------------------------------ Captured log call -------------------------------
WARNING discord.client:client.py:318 PyNaCl is not installed, voice will NOT be supported
=========================== short test summary info ============================
FAILED tests/integration/test_commands_e2e.py::test_add_location_by_name_e2e - AssertionError: assert False

  • where False = .called
  • where = .send_initial_notifications
    ============================== 1 failed in 0.14s ===============================
  1. Observe that is never called
  2. Check database - no entries are created

Proposed Solutions

Option 1: Fix Test Fixtures (Recommended)

  • Align test fixtures with the format expected by
  • Ensure consistent status values across all fixtures
  • Update API mocker to properly simulate the processing layer

Option 2: Enhance API Processing Layer

  • Make the API processing more robust to handle both test and production formats
  • Add format detection and normalization
  • Ensure backward compatibility

Option 3: Standardize Status Handling

  • Define a canonical set of status values
  • Update all API functions to use consistent statuses
  • Update test fixtures to match

Files Involved

    • Command logic and status handling
    • API processing functions like
    • Test fixture files
    • API mocking infrastructure
    • Integration tests

Priority

High - This affects core bot functionality for adding location-based monitoring targets, which is a primary use case.

Related Work

  • PR #57: Export command fix
  • PR #58: Add command partial fix (coordinates working, location search in progress)
  • PR #59: List command channel ID fix

Labels

    • Core functionality not working
    • Affects primary use case
    • Test infrastructure issue
    • API response handling problem

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions