fix(test): point test queue traffic at Azurite instead of real Azure

[Caleb Robinson (calebrob6)]

Problem

The test hatch environment in hastelib/pyproject.toml sets BLOB_CONNECTION_STRING with only a BlobEndpoint override:

...;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;

Config.get_queue_config() reuses that same connection string for queues:

# hastelib/src/hastegeo/core/config.py
"queue_connection_string": os.getenv("BLOB_CONNECTION_STRING"),

Because the string carries no QueueEndpoint, QueueServiceClient.from_connection_string falls back to deriving the default public endpoint rather than the emulator:

>>> QueueServiceClient.from_connection_string(CS).url
'https://devstoreaccount1.queue.core.windows.net/'

That hostname resolves to real Azure Storage infrastructure:

$ getent hosts devstoreaccount1.queue.core.windows.net
20.209.244.229  queue.phx80prdstr23c.store.core.windows.net devstoreaccount1.queue.core.windows.net

So running the test suite locally sends authenticated queue requests off-box to public Azure instead of to Azurite. They fail with AuthenticationFailed (MAC signature mismatch, since the well-known emulator key is not valid there), which surfaces as a confusing test_zip failure that looks like a broken local Azurite setup.

Fix

Add an explicit QueueEndpoint pointing at the Azurite queue port. Port 10001 is already published by docker/docker-compose.yml, so this needs no other setup change:

...;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;

No production code path is affected — this is test-environment configuration only. Only the emulator's well-known public credentials are involved; no secrets are added.

Verification

Run against the local Docker stack (docker compose -f docker/docker-compose.yml up -d):

cd hastelib && hatch run test:pytest
3 failed, 176 passed

Queue traffic now stays on 127.0.0.1. test_zip still fails, but for a different, pre-existing reason unrelated to this change — it progresses past queue creation and then hits stale test drift:

FAILED tests/core/processors/test_artifacts.py::TestArtifactProcessor::test_zip
  - AttributeError: 'ArtifactProcessor' object has no attribute 'zip'

ArtifactProcessor.zip() was refactored into send_to_zip_queue / process_zip / prepare_zip_job / submit_zip_job, but the test was never updated.

Pre-existing failures on main (out of scope, not introduced here)

These 3 failures are present on main before this change and are left alone:

Test	Cause
test_artifacts.py::test_zip	ArtifactProcessor.zip() no longer exists (refactored)
test_imagery_preprocess_config.py::test_config_includes_user_building_footprints_url_when_set	MagicMock(spec=ImageLayer) has no clipBbox
test_imagery_preprocess_config.py::test_config_user_url_is_none_when_unset	same as above

The clipBbox pair stems from 36d23bc adding self.image_data.clipBbox in processors/imagery.py without updating the mock introduced in b2b096e. Happy to fix these in a follow-up PR if wanted.

Note for reviewers

hatch run test:pytest requires the hatch-conda plugin (pip install hatch-conda), since [tool.hatch.envs.test] declares type = "conda". Without it hatch fails with Environment `test` has unknown type: conda. That is not a declared dependency anywhere in the repo — possibly worth documenting separately.

[github-actions]

RC artifacts ready

All branch deployment references use the same RC tag:

• hastegeo_version: 1.0.27rc11
• training_image_tag: 1.0.27rc11
• imageprep_image_tag: 1.0.27rc11
• wheel: hastegeo-1.0.27rc11-py3-none-any.whl

[github-actions]

RC artifacts ready

All branch deployment references use the same RC tag:

• hastegeo_version: 1.0.27rc12
• training_image_tag: 1.0.27rc12
• imageprep_image_tag: 1.0.27rc12
• wheel: hastegeo-1.0.27rc12-py3-none-any.whl

[Anthony Cintron (prbatero)]

LGTM