Pumukit Expired Video Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing to flag is a stack mismatch: despite being PHP, this is not a Laravel package. It is a Symfony bundle (teltek/pumukit-expired-video-bundle) built to plug into Pumukit, the open-source OER video platform maintained by Teltek/UPV. It relies on Symfony's bundle registration and DI container, Doctrine ODM against MongoDB, Pumukit's MultimediaObject/Series/Track domain model, and likely a console command and/or event subscriber that evaluates publication/expiration dates and then unpublishes, archives, or deletes media. For a Laravel codebase, nothing here is drop-in: no service provider, no Eloquent models, no queue integration, no Laravel scheduler hooks.

Integration feasibility. Two paths. (a) You already run Pumukit — then this is a legitimate, low-effort capability add and the main work is configuration and a dry-run validation. (b) You run Laravel or any other PHP stack — the bundle is only useful as a reference implementation. What you would actually reuse is the expiration policy and lifecycle semantics (what counts as expired, what happens to the object, tracks, derivatives, and files), not the code. Reimplementing that as an Artisan command plus a queued job with an expires_at column is measured in days, not weeks.

Technical risk. High, and mostly signal-driven: 1 star, 0 dependents, a single maintainer organization, and a package score near zero. That points to no meaningful external adoption, no community pressure to keep it current, and no evidence of CI, test coverage, versioned releases, or a security policy. Domain risk compounds the supply-chain risk: the bundle's core behavior is destructive (deleting or unpublishing video assets), so a defect is not a rendering glitch — it is data loss. Coupling to Pumukit's internal object model means upgrades to Pumukit can silently break it.

Key questions for the maintainer/owner before committing.

• What precisely defines "expired" — date field, publication status, manual flag, or a combination? Any timezone assumptions?
• Is the default action soft-unpublish, archive, or hard delete? Is media on disk removed, and are transcoded derivatives and thumbnails cascaded?
• What triggers execution — cron/console, Symfony event, or admin UI action — and is there a dry-run or preview mode?
• Is there an audit trail or recoverability path after execution?
• Which Pumukit, Symfony, PHP, and Doctrine ODM versions are supported, and is there any tagged release or changelog?
• What is the license, and who owns the code if the upstream org stops maintaining it?

Integration Approach

Stack fit. Poor for Laravel, good only for Pumukit/Symfony shops. Treat this as "port the policy, not the package." If you are on Pumukit, wire it in via Composer, register the bundle in AppKernel/bundles.php, and configure against your existing MongoDB.

Migration path (Laravel target). Concretely:

1. Read the bundle source end to end and write down the expiration rules as an ADR — this is the deliverable, not the dependency.
2. Model it in your schema: expires_at, expired_at, retention_action (unpublish/archive/delete), plus a soft-delete or deleted_at column.
3. Implement a policy class plus an Artisan command (videos:expire) that dispatches one queued job per video, with an idempotency key.
4. Add storage cleanup as a separate, delayed job so the database state and the object store can be reconciled independently.
5. Ship with a --dry-run flag on day one and keep it as the default for the first two scheduled runs.

Compatibility. Verify Pumukit's pinned Symfony major version, PHP floor, and Doctrine ODM version before anything else; these bundles typically lag the current framework by one or two majors. If your Laravel app is on PHP 8.2+/8.3, assume the source is at best a stylistic reference — it will not be autoloaded alongside your app's dependencies.

Sequencing. (1) Source audit and retention-policy ADR, (2) decision on build-vs-adopt, (3) prototype with dry-run and a single non-production cohort, (4) observability and rollback rehearsal, (5) staged rollout. Do not sequence the deletion path before the audit trail exists.

Operational Impact

Maintenance. Assume you own it. With one star and zero dependents there is no upstream community to absorb framework upgrades; pin to a commit hash, vendor the source if you adopt it, and budget a recurring line item for internal upkeep. The code surface is small, which caps the cost, but "small and unmaintained" still rots against Symfony and MongoDB driver majors.

Support. Community-only via GitHub issues, no SLA, no security disclosure process. For a system that can irreversibly delete production media, that is a governance gap — you need an internal owner on the hook, not a hope that the upstream org responds.

Scaling. The dominant cost is the scan-then-act pattern over the video collection: a full-collection date query every run grows linearly with catalogue size, and the deletion phase is storage-I/O bound rather than CPU bound. Batch the query (cursor-based paging), throttle deletions to avoid saturating the object store or transcoding workers, and ensure the Mongo query is backed by an index on the expiration date field. Notification fan-out (if present) is the other scaling cliff — a mass expiration event can generate thousands of emails in one run.

Failure modes to design against.

• Mass false expiration from a bad date field, timezone drift, or a migration that nulls a date column — mitigate with a dry-run diff, a hard cap on deletions per run, and a kill switch.
• Irreversible loss of media, derivatives, and thumbnails with no restore path — mitigate with soft delete plus a retention window before physical deletion.
• Partial cascade leaving orphaned files or dangling track references — mitigate with a reconciler job and a periodic storage-vs-database audit.
• Overlapping cron runs double-processing the same objects — mitigate with a lock and idempotent jobs.
• Silent no-op after a Pumukit or Symfony upgrade — mitigate with a canary assertion that the command still finds and processes a known test fixture.

Ramp-up. Low code volume, so reading time is a day or two; the real ramp is domain fluency — Pumukit's object model, MongoDB/Doctrine ODM idioms, and your organization's retention and legal-hold requirements. The engineer doing this needs to be comfortable with destructive operations and with the fact that there is effectively no upstream safety net.