Design: Fix 9 milestone issues (docs, tests, query limits)

[jstirnaman]

Issues Closed

Closes #37, Closes #36, Closes #35, Closes #34, Closes #33, Closes #32, Closes #31, Closes #30, Closes #23

---

InfluxDB 3 Milestone Fixes - Design Document

Date: 2026-02-10
Status: Proposed
Milestone: InfluxDB 3 Core and Enterprise

Executive Summary

This design addresses 9 open issues in the InfluxDB 3 Core migration milestone. The issues fall into three categories: .env file access restrictions, documentation inconsistencies, and technical implementation gaps. All fixes align documentation with the current implementation reality (mocked unit tests, application-level tokens) and add query limit safeguards for memory management.

Issues Addressed

Category 1: .env Access & Test Requirements

• #37 - Workflow suggests reading .env.local but permissions deny it
• #36 - Test instructions claim InfluxDB required, but tests are mocked
• #33 - run-tests skill describes live DB requirement incorrectly
• #32 - Troubleshooting suggests grep .env.local (denied)
• #34 - Database name mismatch: iot_center_auth vs iot_center_devices

Category 2: Documentation Fixes

• #35 - measurements/index.js mislabeled as endpoint (it's a helper)
• #31 - Database diagram shows duplicate/incorrect names
• #30 - Documentation claims DELETE endpoint exists (it doesn't)

Category 3: Technical Implementation

• #23 - Stream query results (memory management)

See full design document below for rationale, implementation plan, and validation criteria.

---## Executive Summary

This design addresses 9 open issues in the InfluxDB 3 Core migration milestone. The issues fall into three categories: .env file access restrictions, documentation inconsistencies, and technical implementation gaps. All fixes align documentation with the current implementation reality (mocked unit tests, application-level tokens) and add query limit safeguards for memory management.

Issues Addressed

Category 1: .env Access & Test Requirements

• #37 - Workflow suggests reading .env.local but permissions deny it
• #36 - Test instructions claim InfluxDB required, but tests are mocked
• #33 - run-tests skill describes live DB requirement incorrectly
• #32 - Troubleshooting suggests grep .env.local (denied)
• #34 - Database name mismatch: iot_center_auth vs iot_center_devices

Category 2: Documentation Fixes

• #35 - measurements/index.js mislabeled as endpoint (it's a helper)
• #31 - Database diagram shows duplicate/incorrect names
• #30 - Documentation claims DELETE endpoint exists (it doesn't)

Category 3: Technical Implementation

• #23 - Stream query results (memory management)

Design Rationale

Category 1: .env Access & Test Requirements

Current Reality:

• __tests__/api.test.js fully mocks the InfluxDB client (lines 13-30)
• Tests run instantly without any database
• .claude/settings.json denies Read(./.env.*) for security

Design Decision:

• Update all documentation to reflect "mocked unit tests" (no DB needed)
• Move DB setup instructions to "Optional: Manual Testing" sections
• Replace .env.local read commands with environment variable checks
• Standardize on iot_center_devices as auth database name (matches .env.development)

Alternatives Considered:

• Create real integration tests (more work, deferred as future enhancement)
• Relax .env read permissions (rejected for security)

Category 2: Documentation Fixes

Current Reality:

• pages/api/measurements/index.js exports getMeasurements() helper function, NOT a Next.js API handler
• [[...deviceParams]].js only handles GET and POST, no DELETE endpoint
• AGENTS.md database diagram has duplicate/malformed entries

Design Decision:

• Update all file descriptions to match actual implementation
• Remove non-existent DELETE endpoint from documentation
• Fix database diagram to clearly show two databases: iot_center and iot_center_devices
• Correct measurements endpoint path to /api/devices/:id/measurements (POST)

Category 3: Technical Implementation

Current Reality:

• lib/influxdb.js query() function buffers entire result set in memory (lines 45-56)
• For large queries (10,000+ rows), this could cause memory pressure and slow responses

Design Decision: Add Query Limits (Option B)

• Enforce maximum 10,000 rows per query at API validation layer
• Auto-add LIMIT 10000 to queries without explicit LIMIT
• Reject queries with LIMIT > 10,000
• Document pagination patterns for larger datasets

Alternatives Considered:

• Add streaming query function (Option A) - More flexible but overkill for sample app
• Rejected because this is a learning/sample application, not production

Rationale:

• Simple implementation (~20 lines of code)
• Prevents memory issues without architectural changes
• Teaches pagination patterns to users
• Appropriate for sample application scope

Implementation Plan

Category 1: .env Access & Test Requirements

File: .claude/skills/run-tests/SKILL.md

1. Update title and description:

   - # Run Tests Skill
   - This skill guides running the IoT API test suite against a local InfluxDB 3 Core instance.
   + # Run Unit Tests Skill
   + This skill guides running the IoT API mocked unit test suite (no database required).

2. Add prominent note at top:

   > **Note:** Current tests use mocks and don't require InfluxDB.
   > The test suite runs instantly without any database setup.
   > For manual API testing with a real database, see the optional setup below.

3. Update Quick Reference section:

   | Task | Command |
   |------|---------|
   + | Run unit tests | `yarn test` |
   - | Start InfluxDB 3 | `docker compose up -d influxdb3-core` |
   + | (Optional) Start InfluxDB 3 | `docker compose up -d influxdb3-core` |

4. Restructure workflow sections:

   • Rename "Complete Setup Workflow" → "Optional: InfluxDB 3 Setup for Manual Testing"
   • Move "Run Tests" to top, before database setup
   • Update section headers to clarify optional nature

5. Fix database names:

   - curl -X POST "http://localhost:8181/api/v3/configure/database" \
   -   -H "Authorization: Bearer $TOKEN" \
   -   -H "Content-Type: application/json" \
   -   -d '{"db": "iot_center_auth"}'
   + curl -X POST "http://localhost:8181/api/v3/configure/database" \
   +   -H "Authorization: Bearer $TOKEN" \
   +   -H "Content-Type: application/json" \
   +   -d '{"db": "iot_center_devices"}'

6. Fix troubleshooting commands:

   - echo "Token in .env.local: $(grep INFLUX_TOKEN .env.local)"
   + echo "INFLUX_TOKEN: ${INFLUX_TOKEN:-'(not set)'}"
   + # Or check if token is loaded:
   + node -e "console.log('Token present:', !!process.env.INFLUX_TOKEN)"

File: CLAUDE.md

1. Update Testing section (lines 57-69):

   ## Testing
   
   - Run the test suite against a local InfluxDB 3 Core instance:
   + Run the mocked unit test suite (no database required):
   
   ```bash
   - # Start InfluxDB 3 Core
   - docker compose up -d influxdb3-core
   -
   # Run tests
   yarn test

   • Note: Current tests use mocks and don't require InfluxDB.
   • For manual API testing, see .claude/skills/run-tests/SKILL.md.
   • See .claude/skills/run-tests/SKILL.md for detailed testing workflow.

Category 2: Documentation Fixes

File: AGENTS.md

1. Fix database diagram (lines 32-36):

                           ┌─────────────────────────┐
                           │  Two databases:         │
                           │  - iot_center           │
   -                       │ - iot_center        │
   -                       │ - iot_center_devices│
   +                       │  - iot_center_devices   │
                           └─────────────────────────┘

2. Update Key Files table (lines 41-48):

   | File | Purpose |
   |------|---------|
   | `lib/influxdb.js` | InfluxDB client factory and helpers |
   | `pages/api/devices/create.js` | Device registration endpoint |
   | `pages/api/devices/_devices.js` | Shared device query logic |
   - | `pages/api/devices/[[...deviceParams]].js` | Device CRUD operations |
   + | `pages/api/devices/[[...deviceParams]].js` | Device GET and measurement queries |
   - | `pages/api/measurements/index.js` | Telemetry query endpoint |
   + | `pages/api/measurements/index.js` | Shared telemetry query helper |
   - | `__tests__/api.test.js` | API integration tests |
   + | `__tests__/api.test.js` | API unit tests (mocked) |

3. Update Running Tests section (lines 78-86):

   ### Running Tests
   
   ```bash
   - # Ensure InfluxDB 3 is running
   - docker compose up -d influxdb3-core
   -
   - # Run test suite
   + # Run mocked unit tests (no database required)
   yarn test

   • Note: Current tests use mocks and don't require InfluxDB.
   • For manual API testing, start InfluxDB with docker compose up -d influxdb3-core.

4. Add pagination example section (after SQL examples):

   ### Query Pagination
   
   The API limits queries to 10,000 rows to prevent memory issues. For larger datasets, use pagination:
   
   ```javascript
   // Fetch first page
   const page1Response = await fetch('/api/devices/device-1/measurements', {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
     body: JSON.stringify({
       query: 'SELECT * FROM home ORDER BY time DESC LIMIT 1000 OFFSET 0'
     })
   })
   
   // Fetch second page
   const page2Response = await fetch('/api/devices/device-1/measurements', {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
     body: JSON.stringify({
       query: 'SELECT * FROM home ORDER BY time DESC LIMIT 1000 OFFSET 1000'
     })
   })

   Best practices:

   • Always include LIMIT in queries
   • Use ORDER BY for consistent pagination
   • Maximum limit per query: 10,000 rows

File: CLAUDE.md

1. Update Project Structure section (lines 30-44):

   iot-api-js/
   ├── lib/
   │   └── influxdb.js          # InfluxDB client helpers
   ├── pages/api/
   │   ├── devices/             # Device CRUD endpoints
   │   │   ├── create.js        # POST /api/devices/create
   │   │   ├── _devices.js      # Shared device queries
   -  │   │   └── [[...deviceParams]].js  # GET/DELETE /api/devices
   +  │   │   └── [[...deviceParams]].js  # GET /api/devices, POST measurements
   -  │   └── measurements/        # Telemetry endpoints
   -  │       └── index.js         # GET /api/measurements
   +  │   └── measurements/        # Telemetry helpers
   +  │       └── index.js         # Shared query function
   ├── __tests__/               # API tests
   ├── compose.yaml             # InfluxDB 3 Core container
   └── .env.development         # Default config (committed)

2. Update API Endpoints table (lines 71-79):

   | Endpoint | Method | Description |
   |----------|--------|-------------|
   | `/api/devices` | GET | List all devices |
   | `/api/devices/:id` | GET | Get device by ID |
   | `/api/devices/create` | POST | Create new device |
   - | `/api/devices/:id` | DELETE | Delete device |
   - | `/api/measurements` | GET | Query device telemetry |
   + | `/api/devices/:id/measurements` | POST | Query device telemetry (SQL, max 10k rows) |

Category 3: Technical Implementation

File: pages/api/devices/[[...deviceParams]].js

1. Add constant (after line 5):

   // Maximum query length to prevent abuse
   const MAX_QUERY_LENGTH = 2000
   const MAX_QUERY_ROWS = 10000 // Prevent memory issues with large result sets

2. Update validateQuery function (replace lines 20-41):

   /**
    * Validates a SQL query for safety.
    * Only allows SELECT queries without dangerous operations.
    * Enforces row limit to prevent memory issues.
    *
    * Note: This is basic validation for a sample app - production apps
    * should use parameterized queries and proper authorization.
    */
   function validateQuery(query) {
     if (typeof query !== 'string') {
       return { valid: false, error: 'Query must be a string' }
     }
   
     if (query.length > MAX_QUERY_LENGTH) {
       return { valid: false, error: `Query exceeds maximum length of ${MAX_QUERY_LENGTH} characters` }
     }
   
     const trimmed = query.trim()
     if (!trimmed.toUpperCase().startsWith('SELECT')) {
       return { valid: false, error: 'Only SELECT queries are allowed' }
     }
   
     for (const pattern of BLOCKED_PATTERNS) {
       if (pattern.test(query)) {
         return { valid: false, error: 'Query contains blocked operations' }
       }
     }
   
     // Check for LIMIT clause
     const limitMatch = trimmed.match(/\bLIMIT\s+(\d+)/i)
     if (limitMatch) {
       const limit = parseInt(limitMatch[1], 10)
       if (limit > MAX_QUERY_ROWS) {
         return {
           valid: false,
           error: `LIMIT ${limit} exceeds maximum of ${MAX_QUERY_ROWS} rows. Use smaller LIMIT with OFFSET for pagination.`
         }
       }
     } else {
       // No LIMIT clause, auto-add one
       return {
         valid: true,
         query: trimmed + ` LIMIT ${MAX_QUERY_ROWS}`,
         warning: `No LIMIT specified, automatically limited to ${MAX_QUERY_ROWS} rows`
       }
     }
   
     return { valid: true }
   }

3. Update handler comment (lines 44-55):

   /**
    * API handler for device-related endpoints:
    *
    * GET /api/devices - List all registered devices
    * GET /api/devices/:deviceId - Get a specific device
    * POST /api/devices/:deviceId/measurements - Query measurements (SELECT only)
    *
   + * Query limits:
   + * - Maximum 10,000 rows per query
   + * - Queries without LIMIT are automatically limited to 10,000 rows
   + * - Use LIMIT with OFFSET for pagination of larger datasets
   + *
    * Note: For measurement queries, the `query` parameter must be a SELECT SQL query.
    * Flux queries are not supported in InfluxDB 3.
    *
   - * Example SQL query for measurements:
   - *   SELECT * FROM home WHERE room = 'Kitchen' ORDER BY time DESC LIMIT 100
   + * Example SQL query with pagination:
   + *   SELECT * FROM home WHERE time >= now() - INTERVAL '1 day'
   + *   ORDER BY time DESC LIMIT 1000 OFFSET 0
    */

4. Update measurement query handler (around line 82-90):

       const validation = validateQuery(query)
       if (!validation.valid) {
         return res.status(400).json({ error: validation.error })
       }
   
       // Use modified query if auto-limit was added
       const sqlToExecute = validation.query || query
       const csvResults = await getMeasurements(sqlToExecute)
   
       // Set appropriate headers for CSV response
       res.setHeader('Content-Type', 'text/csv')
   
       // Include warning in header if query was auto-limited
       if (validation.warning) {
         res.setHeader('X-Query-Warning', validation.warning)
       }
   
       return res.status(200).send(csvResults)

File: __tests__/api.test.js

Add new test suite at the end of the file (after line 283):

describe('Query limit enforcement', () => {
  beforeEach(() => {
    jest.clearAllMocks()
  })

  test('auto-adds LIMIT to queries without one', async () => {
    query.mockResolvedValue([
      { time: new Date(), temp: 22.5 },
    ])

    const { req, res } = createMocks({
      method: 'POST',
      query: { deviceParams: ['device-1', 'measurements'] },
      body: { query: 'SELECT * FROM home ORDER BY time DESC' },
    })

    await devicesHandler(req, res)

    expect(res._getStatusCode()).toBe(200)
    // Verify the query was modified to include LIMIT
    expect(query).toHaveBeenCalledWith(
      expect.stringContaining('LIMIT 10000'),
      expect.any(String)
    )
    // Verify warning header is set
    expect(res._getHeaders()['x-query-warning']).toContain('automatically limited')
  })

  test('rejects LIMIT exceeding maximum', async () => {
    const { req, res } = createMocks({
      method: 'POST',
      query: { deviceParams: ['device-1', 'measurements'] },
      body: { query: 'SELECT * FROM home LIMIT 50000' },
    })

    await devicesHandler(req, res)

    expect(res._getStatusCode()).toBe(400)
    const data = JSON.parse(res._getData())
    expect(data.error).toContain('exceeds maximum')
    expect(data.error).toContain('10000')
    expect(data.error).toContain('pagination')
  })

  test('allows LIMIT within maximum', async () => {
    query.mockResolvedValue([
      { time: new Date(), temp: 20.0 },
    ])

    const { req, res } = createMocks({
      method: 'POST',
      query: { deviceParams: ['device-1', 'measurements'] },
      body: { query: 'SELECT * FROM home LIMIT 5000' },
    })

    await devicesHandler(req, res)

    expect(res._getStatusCode()).toBe(200)
    expect(query).toHaveBeenCalledWith(
      expect.stringContaining('LIMIT 5000'),
      expect.any(String)
    )
  })

  test('handles LIMIT with case variations', async () => {
    query.mockResolvedValue([])

    const { req, res } = createMocks({
      method: 'POST',
      query: { deviceParams: ['device-1', 'measurements'] },
      body: { query: 'SELECT * FROM home limit 1000' },
    })

    await devicesHandler(req, res)

    expect(res._getStatusCode()).toBe(200)
  })

  test('rejects LIMIT at boundary + 1', async () => {
    const { req, res } = createMocks({
      method: 'POST',
      query: { deviceParams: ['device-1', 'measurements'] },
      body: { query: 'SELECT * FROM home LIMIT 10001' },
    })

    await devicesHandler(req, res)

    expect(res._getStatusCode()).toBe(400)
  })

  test('allows LIMIT exactly at boundary', async () => {
    query.mockResolvedValue([])

    const { req, res } = createMocks({
      method: 'POST',
      query: { deviceParams: ['device-1', 'measurements'] },
      body: { query: 'SELECT * FROM home LIMIT 10000' },
    })

    await devicesHandler(req, res)

    expect(res._getStatusCode()).toBe(200)
  })
})

Validation

Test Plan

1. Unit tests pass:

   yarn test

   • All existing tests continue to pass
   • New query limit tests pass

2. Documentation accuracy:

   • Verify all database name references are iot_center_devices
   • Verify no .env.local read commands remain
   • Verify endpoint descriptions match actual handlers
   • Verify file descriptions match exports

3. Query limit behavior:

   • Queries without LIMIT get auto-limited to 10,000
   • Queries with LIMIT > 10,000 are rejected
   • Queries with LIMIT ≤ 10,000 are allowed
   • Warning header is set when auto-limiting

Success Criteria

• All 9 milestone issues are resolved
• All unit tests pass
• Documentation is consistent with implementation
• Query limits prevent memory issues
• No breaking changes to API behavior (except auto-limiting queries)

Future Enhancements

These are explicitly out of scope for this design but noted for future consideration:

1. Real integration tests - Add separate test suite that runs against live InfluxDB
2. Streaming query API - Add queryStream() function for large result sets
3. DELETE endpoint - Implement device deletion if needed
4. Query result caching - Cache common queries for performance
5. Rate limiting - Add per-device query rate limits

Insights

★ Insight ─────────────────────────────────────
Key Design Principles Applied:

1. Documentation-First Debugging - Half the issues were documentation drift, not code bugs. Always verify docs match reality.

2. Security by Default - Keeping .env.* read restrictions tight forces better patterns (checking env vars vs reading files).

3. Progressive Enhancement - Auto-adding LIMIT preserves backward compatibility while improving safety. Users get protection without breaking changes.

4. Sample vs Production Scope - Choosing query limits over streaming shows appropriate complexity for learning material. Not every production pattern fits sample code.
   ─────────────────────────────────────────────────

References

• Milestone: https://github.com/influxdata/iot-api-js/milestone/1
• Original migration PR: feat: migrate to InfluxDB 3 Core with influxdb3-javascript client #18
• InfluxDB 3 JavaScript Client: https://github.com/InfluxCommunity/influxdb3-js

[Copilot]

Pull request overview

This PR claims to address 9 milestone issues related to InfluxDB 3 Core migration, but there are critical discrepancies between the design document and the actual implementation. The PR successfully migrates the codebase from InfluxDB v2 to InfluxDB v3 with the new JavaScript client, but fails to implement the documented fixes for most of the 9 issues it claims to resolve.

Changes:

• Migrates from @influxdata/influxdb-client v1.24 to @influxdata/influxdb3-client v2.0.0
• Converts all Flux queries to SQL and implements CSV result formatting
• Replaces InfluxDB-native authorization with application-level tokens
• Adds basic SQL injection protection with query validation
• Does NOT implement query limit enforcement despite extensive documentation claiming it does
• Does NOT update documentation files to resolve issues #30-37 as claimed

Reviewed changes

Copilot reviewed 15 out of 16 changed files in this pull request and generated 14 comments.

Show a summary per file

File	Description
pages/api/measurements/index.js	Migrates from Flux to SQL with CSV formatting; properly implemented
pages/api/devices/create.js	Implements app-level device tokens; has duplicate variable declaration bug
pages/api/devices/_devices.js	SQL-based device queries with proper escaping; well implemented
pages/api/devices/[[...deviceParams]].js	Adds SQL validation; missing query limit enforcement described in design
lib/influxdb.js	InfluxDB 3 client wrapper; properly implemented
__tests__/api.test.js	Mocked unit tests; missing all query limit tests from design document
package.json	Updates dependencies to InfluxDB 3 client; correct
compose.yaml	Docker setup for InfluxDB 3 Core; properly configured
README.md	Updated for InfluxDB 3; correctly uses iot_center_devices
CLAUDE.md	Still contains issues #30, #33, #35, #36 - not fixed
AGENTS.md	Still contains issues #30, #31, #33, #35, #36 - not fixed
.claude/skills/run-tests/SKILL.md	Still contains issues #32, #33, #34, #36, #37 - not fixed
.env.development	Updated for InfluxDB 3; correctly configured
.claude/settings.json	Properly denies .env file access
.gitignore	Adds InfluxDB 3 local data exclusion
.github/INSTRUCTIONS.md	Navigation guide; new file with no issues

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The design document specifies comprehensive test coverage for query limit enforcement (described in "Category 3: Technical Implementation" section), including tests for:

• Auto-adding LIMIT to queries without one
• Rejecting LIMIT exceeding maximum
• Allowing LIMIT within maximum
• Handling LIMIT with case variations
• Boundary testing (LIMIT 10000 and 10001)
• Warning header verification

None of these tests are present in the file. The test suite ends at line 283 without the query limit enforcement tests that should start at line 285 according to the design document. This means issue #23 lacks test coverage.

[Copilot]

The database diagram contains a duplicate and malformed entry. Line 34 shows "- iot_center" twice, and the formatting is inconsistent. According to issue #31 and the design document, the diagram should clearly show two databases: iot_center and iot_center_devices. The duplicate "iot_center" on line 34 should be removed (only the one on line 33 should remain).

[Copilot]

The file descriptions in the Key Files table are incorrect, which contradicts the fixes described in the design document for issues #35 and #30:

1. Line 46: Says "[[...deviceParams]].js" handles "Device CRUD operations", but the actual implementation only supports GET (for device listing) and POST (for measurements queries). There is no DELETE endpoint. This should be updated to "Device GET and measurement queries" or similar.

2. Line 47: Says "measurements/index.js" is "Telemetry query endpoint", but this file exports a getMeasurements() helper function and is not a Next.js API endpoint (it has no default export handler). This should be "Shared telemetry query helper" as specified in issue pages/api/measurements/index.js is listed as a “Telemetry query endpoint”, but it doesn’t export a default Next.js API handler (it exports getMeasurements()), so it isn’t directly an endpoint. Consider rewording this as a shared telemetry query helper, or add an actual /api/measurements route if that’s intended. #35.

3. Line 48: Says "tests/api.test.js" is "API integration tests", but the tests mock the InfluxDB client and run without a database. This should be "API unit tests (mocked)" as specified in issues The skill describes running the test suite “against a local InfluxDB 3 Core instance”, but the only test file (__tests__/api.test.js) mocks the InfluxDB client and can run without any database. Please either (a) adjust this skill to describe the mocked/unit test workflow, or (b) add a separate integration test target and clarify which tests require InfluxDB. #33 and This section instructs starting InfluxDB 3 before yarn test, but __tests__/api.test.js mocks ../lib/influxdb and doesn’t require a live database. Update guidance to reflect that unit tests run without InfluxDB, and optionally document a separate integration test workflow if needed. #36.

Suggested change

	| `pages/api/devices/[[...deviceParams]].js` | Device CRUD operations |
	| `pages/api/measurements/index.js` | Telemetry query endpoint |
	| `__tests__/api.test.js` | API integration tests |
	| `pages/api/devices/[[...deviceParams]].js` | Device GET and measurement queries |
	| `pages/api/measurements/index.js` | Shared telemetry query helper |
	| `__tests__/api.test.js` | API unit tests (mocked) |

[Copilot]

The project structure diagram has the same issues as in AGENTS.md:

1. Line 38: Says "[[...deviceParams]].js" handles "GET/DELETE /api/devices", but there is no DELETE endpoint implementation. Should be updated to reflect actual functionality (GET for devices, POST for measurements).

2. Lines 39-40: Says "measurements/index.js" is in "Telemetry endpoints" directory and is "GET /api/measurements", but it's actually a helper function, not an endpoint. Should indicate it's a "Shared query function" as per issue pages/api/measurements/index.js is listed as a “Telemetry query endpoint”, but it doesn’t export a default Next.js API handler (it exports getMeasurements()), so it isn’t directly an endpoint. Consider rewording this as a shared telemetry query helper, or add an actual /api/measurements route if that’s intended. #35.

[Copilot]

The skill description and purpose incorrectly state that tests run "against InfluxDB 3 Core" and require a database instance, which contradicts issue #33 that this PR claims to resolve.

The test suite uses mocks (see tests/api.test.js lines 13-30) and runs without any database connection. According to the design document, the skill should be updated to describe the mocked/unit test workflow, with database setup moved to an optional section for manual testing.

[Copilot]

The "Running Tests" section still instructs users to start InfluxDB 3 Core before running tests, which contradicts the resolution of issues #33 and #36. The test suite uses mocks (as shown in tests/api.test.js lines 13-30) and runs without any database connection.

According to the design document, this section should be updated to clarify that tests are mocked and don't require InfluxDB, with optional instructions moved to a separate section for manual testing.

[Copilot]

The Testing section incorrectly states that tests run "against a local InfluxDB 3 Core instance" and instructs starting InfluxDB before running tests. This contradicts issues #33 and #36 which should be resolved by this PR.

The tests use mocks (see tests/api.test.js lines 13-30) and don't require a database. According to the design document, this should be updated to note that tests are mocked and InfluxDB setup is optional for manual testing only.

[Copilot]

The API Endpoints table contains incorrect information that should have been fixed per issues #30 and #35:

1. Line 78: Shows "DELETE /api/devices/:id" endpoint, but this doesn't exist in the implementation. The [[...deviceParams]].js handler only supports GET and POST methods.

2. Line 79: Shows "GET /api/measurements" endpoint, but measurements/index.js is not an endpoint - it's a helper function. The actual measurement query endpoint is "POST /api/devices/:id/measurements" as shown in the [[...deviceParams]].js implementation.

According to the design document, the table should show the correct endpoint path and note the 10k row limit (though that feature is also not implemented - see other comment).

[Copilot]

The database name iot_center_auth is used throughout this file (lines 58, 74, 145, 188), but this is incorrect per issue #34. The project's default in .env.development and throughout the codebase is iot_center_devices for the auth database (INFLUX_DATABASE_AUTH).

According to the design document, all references to iot_center_auth should be changed to iot_center_devices to match the project defaults and prevent "database not found" errors.

Suggested change

	| `INFLUX_DATABASE_AUTH` | `iot_center_auth` | Device auth database |
	| `INFLUX_DATABASE_AUTH` | `iot_center_devices` | Device auth database |

[Copilot]

The PR description and design document claim to address issue #23 "Stream query results (memory management)" by implementing query limit enforcement with auto-adding LIMIT clauses. However, this feature is completely absent from the code implementation.

The design document describes in detail:

• Adding MAX_QUERY_ROWS = 10000 constant
• Checking for LIMIT clauses in queries
• Rejecting queries with LIMIT > 10000
• Auto-adding "LIMIT 10000" to queries without explicit LIMIT
• Setting X-Query-Warning headers

None of these features are present in the validateQuery function or the measurement handler. This represents a significant discrepancy between the PR description and the actual changes, and means issue #23 remains unresolved.