fix(vanity-url): unpublish canonical page

[syedATdot]

This PR incorporates changes from @riccardoruocco's fork.

Fixes #35663

[mergify]

⚠️ The sha of the head commit of this PR conflicts with #36185. Mergify cannot evaluate rules on this PR. Once #36185 is merged or closed, Mergify will resume processing this PR. ⚠️

[github-actions]

🤖 Bedrock Review — deepseek.v3.2

[🟠 High] dotCMS/src/enterprise/java/com/dotcms/enterprise/publishing/staticpublishing/AWSS3Publisher.java:391 — The call to unpublishVanityAliasesForCanonicalFileIfEnabled passes a S3VanityAliasContext constructed with file, but the file variable is the canonical file being deleted. The method unpublishAliases later uses context.endpointPublisher.acceptsFile(context.file); if the file is already deleted or invalid, this check may fail incorrectly, causing aliases not to be cleaned up.

[🟡 Medium] dotCMS/src/enterprise/java/com/dotcms/enterprise/publishing/staticpublishing/S3VanityAliasService.java:586-595 — In unpublishAliases, the loop calls removeMaterializedAlias for each alias, which may throw an exception. If an exception occurs after some aliases have been removed (added to removedNow), the catch block calls restoreAliases but passes the original context (which contains the deleted canonical file) instead of the cleanupContext built inside the method. This could lead to incorrect restoration logic because restoreAliases expects a S3VanityAliasContext with the original file, not the cleanup context.

[🟡 Medium] dotCMS/src/enterprise/java/com/dotcms/enterprise/publishing/staticpublishing/S3VanityAliasService.java:588 — The loop iterates over persistedAliases and calls removeMaterializedAlias directly, but removeMaterializedAlias is a private method that may have side effects (like deleting from S3). If it fails after some deletions, the restoreAliases may not fully restore because the deletions are partial. There's no transaction wrapping this operation, which could leave the system in an inconsistent state (some aliases deleted from S3 but not from DB, or vice versa). Consider @WrapInTransaction if the repository delete is also in the same transaction.

[🟡 Medium] dotCMS/src/main/java/com/dotmarketing/startup/runonce/Task260507CreateS3VanityAliasTable.java:46-60 — The DDL script uses varchar without length for some columns (canonical_path, vanity_path, bucket_name, bucket_region, bucket_prefix), which in PostgreSQL defaults to varchar(255)? Actually, the script defines them as varchar (unlimited). This is inconsistent with the explicit lengths set for other columns (e.g., varchar(36)). While not a bug, it deviates from the explicit lengths in the renamed task file (lines 46-60 show lengths for those columns). The postgres.sql file (line 2284 onward) also uses varchar without length for those columns, causing a mismatch. This could lead to schema differences if the task is run after initial install.

[🟡 Medium] dotCMS/src/test/java/com/dotcms/enterprise/publishing/staticpublishing/S3VanityAliasServiceTest.java:130-133 — The test unpublishAliasesShouldReturnVoidAndSkipS3WhenNoAliasesArePersisted verifies that deleteFilesFromEndpoint is never called, but the mock setup doesn't guarantee that removeMaterializedAlias (which calls the endpoint) is not invoked. Since removeMaterializedAlias is private and called within the loop, the test may not be accurately reflecting the behavior if the method is refactored. The test should also verify that removeMaterializedAlias is not called (maybe by verifying interactions on the endpointPublisher).

---

_{Run: #27825222854 · tokens: in: 6007 · out: 827 · total: 6834}