Error while running wolfram_client.aquery

[snemmani]

lately I have been getting this weird error in this file while running wolfram_client.aquery() when i ask a question like "Define something".

The Error is as below

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\Users\myUser\dev\app\venv\Lib\site-packages\wolframalpha\__init__.py", line 129, in aquery
    assert resp.headers['Content-Type'] == 'text/xml;charset=utf-8'
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

I wasn't getting this earlier.

I am using wolfram client version wolframalpha==5.1.3

[slk000]

update the assertion as in
#34

[austin-bowen]

I am also awaiting this fix 🙏 will try to get around it in the meantime using the python -O flag (disables assert statements)

[austin-bowen]

FWIW I wonder if the assert is even necessary. I think it should be deleted (and let the XML parser blow up), or improve the check to be more robust and have a descriptive error message. Getting just AssertionError is not helpful

[sudhir2016]

Hope this gets resolved soon.

[codetasks]

Confirming the root cause and that this now reproduces on every query, not just "Define" style inputs.

The API's response header changed: as of 2026-06-07, curl -sI "https://api.wolframalpha.com/v2/query?appid=...&input=2%2B2" returns

content-type: text/xml; charset=utf-8

(note the space after the semicolon), while aquery() line 129 asserts the exact string 'text/xml;charset=utf-8'. The exact match fails, so aquery raises AssertionError on every call. The synchronous path is unaffected because only aquery carries this assert.

Downstream impact: any wrapper built on aquery is fully broken, e.g. the mcp-wolfram-alpha MCP server (0.2.1) catches this and reports only "Failed to query Wolfram Alpha", which makes the failure hard to trace back here.

#36 fixes this correctly: the lowercased live header contains both text/xml and charset=utf-8, so its relaxed check passes (verified against the live API today). A slightly more robust variant would drop the charset assertion entirely or parse the header with email.message.Message, since RFC 9110 treats parameters as case insensitive and optionally spaced, but the PR as written works. Would be great to see it merged and released.