Remove duplicate query logging that breaks Django's assertNumQueries

[federicobond]

The SqlCommenter _QueryWrapper manually appends the SQL string to queries_log when a CursorDebugWrapper is active. However, CursorDebugWrapper.debug_sql already logs the query as a dict with "sql" and "time" keys. This causes two problems:

1. Queries are double-counted in queries_log
2. The raw string entries cause a TypeError in Django's assertNumQueries, which expects dict entries with a "sql" key

Remove the manual append and let Django handle query logging.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Tested against a Django project that was failing a test case:

         with self.assertNumQueries(14):
              ^^^^^^^^^^^^^^^^^^^^^^^^^
     E   TypeError: string indices must be integers, not 'str'

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[tammy-baylis-swi]

Thanks for catching this! Could unit test coverage be added here on OTel Contrib side? Maybe it could borrow from your other-project test case that does the self.assertNumQueries(14).

[federicobond]

@tammy-baylis-swi I tried but found it hard to come up with a meaningful test that it does NOT mess with the query log. Could be something like this, but still feels a bit artificial:

connection = MagicMock()
connection.queries_log = deque()
connection.force_debug_cursor = False

with CaptureQueriesContext(connection) as ctx:
    qw_instance = _QueryWrapper(requests_mock)
    execute_mock = MagicMock()
    context = {"cursor": MagicMock(), "connection": connection}
    qw_instance(
        execute_mock, "SELECT 1", MagicMock(), MagicMock(), context
    )

self.assertEqual(len(ctx), 0)

[tammy-baylis-swi]

@tammy-baylis-swi I tried but found it hard to come up with a meaningful test that it does NOT mess with the query log. Could be something like this, but still feels a bit artificial:

Agree that it's quite mock-y @federicobond , which reminds me that we've been wanting to add proper db client testing for a while but haven't gotten to it with all else going on: #3032

Maybe a quick unit test is better than nothing for now? Would be good to get other Approvers' thoughts.

[federicobond]

I'm not sure it's worth it to add a test here to be honest. There was never a test for the original query log behavior to begin with.

[github-actions]

This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment.
If you're still working on this, please add a comment or push new commits.

[federicobond]

This issue is still relevant. Pull request is just waiting for a second approval

[tammy-baylis-swi]

Maintainers, please have a look.

[emdneto]

Thanks for the PR!

Just a heads-up: we no longer update CHANGELOG.md directly. The changelog is now generated from changelog fragments using Towncrier.

Please add the appropriate changelog fragment for this change instead of editing CHANGELOG.md manually. You can find the instructions and expected format in CONTRIBUTING.md.

[federicobond]

Done, let me know if I've correctly added the changelog entry.