additional-spring-configuration-metadata.json

{
    "properties": [
        {
            "name": "aboutbits.emailservice.migrations.enabled",
            "type": "java.lang.Boolean",
            "description": "Enables database migrations.",
            "defaultValue": true
        },
        {
            "name": "aboutbits.emailservice.scheduling.enabled",
            "type": "java.lang.Boolean",
            "description": "Enables the scheduler sending the emails.",
            "defaultValue": true
        },
        {
            "name": "aboutbits.emailservice.scheduling.cleanup.enabled",
            "type": "java.lang.Boolean",
            "description": "Enables cleanup of attachment files after sending.",
            "defaultValue": true
        },
        {
            "name": "aboutbits.emailservice.scheduling.interval",
            "type": "java.lang.Long",
            "description": "Specifies the milliseconds delay between runs of the scheduler.",
            "defaultValue": 30000
        },
        {
            "name": "aboutbits.emailservice.scheduling.stuck-sending-recovery-threshold",
            "type": "java.time.Duration",
            "description": "How long an email may stay in the SENDING state before being considered abandoned (crashed pod) and eligible to be re-claimed by another pod. Must comfortably exceed the worst-case SMTP send duration: JavaMail's default connect/read/write timeouts are infinite, so configure spring.mail.properties.mail.smtp.connectiontimeout, spring.mail.properties.mail.smtp.timeout and spring.mail.properties.mail.smtp.writetimeout well below this threshold, otherwise a slow in-flight send can be re-claimed by another pod and delivered twice.",
            "defaultValue": "PT30M"
        },
        {
            "name": "aboutbits.emailservice.scheduling.stuck-cleanup-recovery-threshold",
            "type": "java.time.Duration",
            "description": "How long an email may keep its attachment-cleanup lock before the cleanup is considered abandoned (crashed pod) and eligible to be re-claimed. Must comfortably exceed the worst-case duration of releasing all attachments of a single email, otherwise a slow in-flight cleanup can be re-claimed by another pod and its attachments released twice (harmless only if `AttachmentDataSource.releaseAttachment` is idempotent).",
            "defaultValue": "PT30M"
        },
        {
            "name": "aboutbits.emailservice.scheduling.max-attempts",
            "type": "java.lang.Integer",
            "description": "Maximum number of send attempts before an email is marked as ERROR. Applies to the scheduled retry loop; the synchronous sendOrFail path is fail-fast and does not retry. Failed attempts are retried with exponential backoff (scheduling.interval x 2^attempts); with the defaults a persistently failing email runs attempt 1 -> +60s -> attempt 2 -> +120s -> attempt 3 -> ERROR.",
            "defaultValue": 3
        }
    ]
}