- Inspect the dokploy-vector service before listing tasks; listTasks returns [] for a missing service
- Filter provider assignments to existing providers after a deploy so a provider deleted mid-deploy is not written back
- Check accessedServers on deploy, removal and the server-status list
- Keep the local claim until the agent is removed and serialize deploy/remove per target
- Persist provider assignments only after the Vector deploy succeeds; release the local claim if the first deploy fails
- Remove the agent on server/organization deletion even when no providers remain assigned
- Report agents with no running task as not running
- Refresh logProvider.one after saving, allow clearing saved credentials, keep deployed targets visible with no providers
The HubSpot script is loaded app-wide with loadImmediately: false, but
useHubSpotChat was never called, so widget.load() never ran. The old
HubSpotWidget shared the hs-script-loader id and was deduped by next/script.
- Updated API link conditions to allow skipping batch processing based on context.
- Removed unused VECTOR_RESYNC_CRON_JOB constant from server constants.
- Introduced logProviderIds field in server and webServerSettings schemas to manage log providers.
- Added organization service to handle organization deletions and vector agent removals.
- Enhanced server service to find servers with log management enabled and update log providers.
- Updated vector setup to sync vector configurations based on organization and server log provider IDs.
- Implemented Docker labels for resources to improve tracking and management.
- Refactored vector agent setup and removal processes to streamline operations.
Switching plan mid-trial always forced the monthly price and there was no
way to move to annual. Preserve trial_end on the Stripe update so changing
the interval does not reset the billing cycle and end the trial early.
Cloud runs two frontend replicas and node-schedule fires on each, so both
would read the same unset marker and every trial user would get the email
twice. A Postgres advisory lock lets one replica run and the other skip;
it lives in the connection rather than the schema, so no migration.
Drops the 3-day reminder, leaving the single notice before billing starts.
Stripe merges metadata on update, so spreading the snapshot read during
the list call re-asserted stale values over anything written since. Send
only the key being claimed.
The claim is not exclusive and the comment no longer says it is: two
replicas can still read the same unset marker. Marking before the send
only keeps a crash mid-send from resending on the next run.
Narciso