{"version":"2.1.282","anchor":"artifact-publish-reserves-a-slug-first-and-falls-back-to-le","canonical_anchor":"artifact-publish-reserves-a-slug-first-and-falls-back-to-le","heading":"Artifact publishing reserves a name first and records which path it took","tier":"notice","area":"Artifacts","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/artifact-publish-reserves-a-slug-first-and-falls-back-to-le","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### Artifact publishing reserves a name first and records which path it took\n\nThe Artifact tool now tries to reserve a slug before uploading, falls back to a server-assigned one, and records the publish path and omitted files\n\n**Unclear.** Which \"not found\" errors on republishing are now handled differently is not stated.\n\n**What**\n\nWhen the Artifact tool publishes an artifact, it now works differently:\n\n- If the publish has no slug yet (the short name in the artifact's web address), the tool first tries to reserve one before uploading.\n\n- If the reservation fails, it writes a debug line (\"could not reserve a slug before publishing\") and publishes anyway, leaving the server to assign the slug. A 403 or 404 response on the reserve step is not reported as `reserve_unavailable`; any other failure is.\n\n- A 404 response on a redeploy is no longer always reported as `multifile_unsupported`; some of those 404s are now exempt.\n\n- A successful publish now records how many files were left out and which path it took: \"preflight\", \"legacy\" or \"inline\".\n\nBefore, a publish with no slug went straight to uploading.\n\n**Why**\n\nPublishes that start without a slug now try to get one before uploading, and still go through if that step fails. Fewer redeploy failures are reported as unsupported multi-file publishes.\n\n- Area: Artifacts\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5"}