Skip to content

limitations.md

Latest commit

 

History

History
27 lines (20 loc) · 4.7 KB

limitations.md

File metadata and controls

27 lines (20 loc) · 4.7 KB
Raw

Limitations

Explicit, honest list of what this package deliberately does not do.

  • No business logic or orchestration. This is a thin Saloon-based REST wrapper — typed Request classes and fluent Resource gateways, nothing more. Provisioning sequences, retry/backoff policy beyond the built-in Saloon retry, idempotency across multiple calls, and long-running-operation orchestration beyond the provided polling helpers are the consuming app's responsibility.
  • No official microsoft/* Azure SDK dependency. Every surface is a hand-written Saloon Request/DTO pair against the documented REST API, not a wrapped SDK client. See ENDPOINTS.md for the full endpoint catalog.
  • No .NET SDK or Agent Framework runtime code. The Foundry Agent Service and Function Runtime surfaces call the HTTP APIs those runtimes expose — they don't embed or replace the Agent Framework WorkflowBuilder graph-authoring SDK (.NET/Python only).
  • No database migrations or application seeding. Deploying a schema into a provisioned Azure SQL database (or similar) is out of scope — bring your own migration runner.
  • No service health checks. The package makes the calls you ask it to; it doesn't poll third-party "is this service up" endpoints.
  • Actual-state reads are per-resource and control-plane. observe() (see Advanced usage) issues one ARM/Graph read for one named resource. There is no bulk "what exists in this subscription" sweep — Azure Resource Graph is not wrapped — so a caller reconciling many resources issues many reads. And Available is an ARM answer: it means the resource is provisioned, not that its data plane will serve you. secrets()->observeAccess() is the only data-plane reachability probe the package ships; other surfaces need their own read.
  • Pre-1.0 / dev-stability. composer.json sets minimum-stability: dev; the released line is v0.x. Expect breaking changes between minor versions until 1.0. (Note: a v1.0 tag exists but points at the same commit as v0.11.0 — it was cut by hand, not by the release workflow, and does not denote a 1.0 API. See Release tags.)
  • PHP 8.4/8.5 and Laravel 13 only. No legacy PHP or Laravel support — see Installation.
  • API Management coverage is subscriptions/keys only. Products, policies, APIs, named values, and users are not covered — see Logic Apps & API Management.
  • Foundry Agent Service sub-surfaces vary in maturity. Memory Stores, Evaluations, Schedules, Datasets, Indexes, and Redteams are lower-priority/preview additions with rougher edges than the core Agents/Responses/Conversations surface — see Foundry Agent Service. Legacy Threads/Runs (Assistants-style) are marked deprecated by Microsoft (sunset August 2026).
  • Response bodies aren't redacted on success paths. src/Security/Redactor.php only scrubs known secret-shaped fields in error summaries. If you log full response bodies (debug.capture_bodies), some surfaces can return credential material in a 200 response — see Configuration → Security.
  • A known config-drift bug currently makes the cache-lifetime and request-timeout env vars no-ops — see Configuration → Known drift.

For the design rationale behind the current surface set (why some things were deliberately left out), see docs/REFACTOR.md.

Release tags

Tags are cut automatically by .github/workflows/release.yml (anothrNick/github-tag-action, default bump: minor) when a pull request against main is merged.

  • An unmerged pull request no longer tags — fixed. The workflow triggers on pull_request: types: [closed], which fires for abandoned pull requests as well as merged ones, so the release job now carries if: github.event.pull_request.merged == true. Closing a pull request without merging it is a no-op. Until that guard was added, closing one without merging also bumped the version and pushed a tag for code that never reached main.
  • A hand-cut tag is still not guarded against. Composer derives versions from git tags — there is no version field in composer.json to check a tag against (and there should not be one; Composer's own guidance is to omit it). Nothing verifies that a tag was produced by the workflow, and a tag pushed by hand is installable immediately. v1.0 and v0.11.0 both point at commit b9058b5; v0.1 points at a commit that is not an ancestor of main at all.

Release by merging a pull request into main and letting the workflow tag. Do not push tags by hand.