app

type DryRunResult ¶

type DryRunResult struct {
	OrphansWouldDelete map[domain.PhotoClass][]domain.StorageRef
}

DryRunResult summarizes one DryRun: exactly which orphaned objects each class's sweep WOULD delete — refs, not just a count — so an operator can inspect them before ever running the destructive Run.

type PhotoService ¶

type PhotoService struct {
	// contains filtered or unexported fields
}

PhotoService handles uploading and deleting photos of ONE registered domain.PhotoClass: it streams the bytes behind the PhotoStore under that class, dedups by content hash, captures the EXIF date, and persists the photo metadata. class is fixed at construction (NewPhotoService), so a caller needing more than one class (e.g. Nestova's album AND chore-proof uploads) constructs one PhotoService per class rather than passing class per call — this is what keeps the upload use case identical for every consumer while still namespacing each class's bytes.

WRITES vs READS resolve to a PhotoStore differently (the mixed-state fix — see domain.PhotoStoreResolver's doc for the full argument): Upload always writes new bytes to writeBackend, the ONE backend this deployment is currently configured to write new photos to; every read (OpenBytes, RawServe, the EXIF-reopen inside Upload itself) resolves the STORE for the SPECIFIC ROW being read, via its own persisted Photo.StorageBackend — which may differ from writeBackend for a row written before an operator switched backends, or mid-migration. Resolving reads by the row's own backend, not a single fixed store, is what makes a mixed-state deployment's existing photos remain readable after a backend switch.

func NewPhotoService(class domain.PhotoClass, resolver domain.PhotoStoreResolver, writeBackend domain.StorageBackend, exif domain.ExifReader, photos domain.PhotoRepository) (*PhotoService, error)

func (s *PhotoService) Delete(ctx context.Context, householdID identity.HouseholdID, id domain.PhotoID) error

func (s *PhotoService) List(ctx context.Context, householdID identity.HouseholdID) ([]*domain.Photo, error)

func (s *PhotoService) OpenBytes(ctx context.Context, householdID identity.HouseholdID, id domain.PhotoID) (io.ReadCloser, string, error)

func (s *PhotoService) RawServe(ctx context.Context, householdID identity.HouseholdID, id domain.PhotoID) (RawServeResult, error)

func (s *PhotoService) Upload(ctx context.Context, householdID identity.HouseholdID, uploaderID identity.MemberID, r io.Reader) (UploadResult, error)

type RawServeResult ¶

type RawServeResult struct {
	RedirectURL string
	Body        io.ReadCloser
	ContentType string
}

RawServeResult is what PhotoService.RawServe returns: exactly one of RedirectURL (non-empty) or Body (non-nil) is set, mirroring the two ways a PhotoStore backend can serve bytes — see domain.PhotoStore. SupportsDirectURL's doc. RedirectURL is a presigned URL the caller should 302 the client to, bypassing the calling process entirely (an S3-backed store); Body is a stream the caller must copy through and Close (a local-filesystem store, which has no browser-navigable URL to hand back).

type ReapableSource ¶

type ReapableSource interface {
	ListAllStorageRefs(ctx context.Context, backend domain.StorageBackend) ([]domain.StorageRef, error)
	ExistsByStorageRef(ctx context.Context, ref domain.StorageRef, backend domain.StorageBackend) (bool, error)
}

ReapableSource is the narrow, class-scoped read surface a ReaperService needs from a registered domain.PhotoClass's own repository: which refs it still references, and whether one specific ref is still referenced. domain.PhotoRepository satisfies this structurally (no adapter needs to declare the assertion), and so does any other application-owned repository sharing the same two methods — e.g. a chore-proof-specific repository carrying its own extra retention methods this interface deliberately does not require (ISP): retention (deciding when to delete a ROW) is an application policy, not shared media plumbing, and stays entirely on the caller's side of Run.

type ReaperResult ¶

type ReaperResult struct {
	OrphansDeleted map[domain.PhotoClass]int
}

ReaperResult summarizes one Run: how many orphaned objects the sweep deleted per class.

type ReaperService ¶

type ReaperService struct {
	// contains filtered or unexported fields
}

ReaperService reclaims orphaned PhotoStore objects for an object-store backend: objects a repository's rows-only Delete leaves behind once nothing references them. It is generic over sources — one ReapableSource per domain.PhotoClass the caller wants swept — so a new class (a new consumer's own registered PhotoClass) is reaped by adding an entry to the map passed to NewReaperService, never by editing this package.

Never invoked automatically: reaping is destructive (it permanently deletes object-store bytes), so wiring an unattended timer is a caller-side decision this package does not make for it.

One pass per Run call: list every stored object of each registered class (lister.ListObjects), compute the set of StorageRefs still referenced by ANY source in sources (across every class, not just the class being swept — a row from one class's source can legitimately reference an object filed under a DIFFERENT class's own key prefix), and delete any object that is BOTH unreferenced AND older than graceWindow — an object younger than the grace window might be mid-upload (Put has written bytes but Create has not yet committed the referencing row), not genuinely orphaned; see domain.ObjectInfo.LastModified's doc.

This design makes "restore a week-old DB backup against the same bucket" safe by construction: a restored row's StorageRef reappears in the referenced-set computation on the very next Run, so an object the reaper has not yet reached is protected again before it is ever deleted.

TOCTOU note (deletion race): the referenced-set snapshot and the object listing are each taken once, up front, but a row can commit at any point after that snapshot. To narrow that window, Run re-checks EACH candidate individually, via a targeted ExistsByStorageRef query against every source, in the SAME loop iteration immediately before deleting it — this closes the gap down to the single instant between that final check and the delete call itself. That residual instant is NOT closed by this design; Run is intended to be invoked by an operator, never automatically, and MUST NOT be run concurrently with a database restore.

func NewReaperService(
	store domain.PhotoStore,
	backend domain.StorageBackend,
	sources map[domain.PhotoClass]ReapableSource,
	graceWindow time.Duration,
) (*ReaperService, error)

func (r *ReaperService) DryRun(ctx context.Context, now time.Time) (DryRunResult, error)

func (r *ReaperService) Run(ctx context.Context, now time.Time) (ReaperResult, error)

type UploadResult ¶

type UploadResult struct {
	Photo     *domain.Photo
	Duplicate bool
}

UploadResult is the outcome of PhotoService.Upload: the photo that now represents the upload, and whether it was a re-drop of bytes the household already has (Duplicate) rather than a newly created row.