Application environment editor reverts to stale value after a successful save

To Reproduce

1. Open an Application → Environment.
2. Change an existing value, for example TIMEFRAME=15m to TIMEFRAME=150m.
3. Save with Ctrl/Cmd+S.
4. Immediately change it again, for example TIMEFRAME=150m to TIMEFRAME=151m, and save.
5. Observe the editor after the save and then refresh the page.

Current vs. Expected behavior

Current

The editor briefly shows the just-saved value, then reverts to the previous value. For example, after saving 151m, it can show 150m again. The caret also jumps to the first line when this happens.

A full page refresh shows the last value actually saved to the backend. In the example, after saving 151m → 15m, the editor can visually return to 151m, while refresh correctly shows 15m. This can cause a user to save the stale value again accidentally.

Expected

After a successful save, the editor must retain saved text and caret/scroll position. A polling response started before the mutation must not overwrite the saved form state.

Root cause

The application detail page polls application.one every 5 seconds:

apps/dokploy/pages/dashboard/project/[projectId]/environment/[environmentId]/services/application/[applicationId].tsx

api.application.one.useQuery({ applicationId }, { refetchInterval: 5000 });

ShowEnvironment shares that query. PR #4626 correctly avoids resetting while the form is dirty, but its successful-save path calls form.reset(formData), which clears isDirty. A pre-save polling response may then resolve with old data; the effect accepts it because !isDirty and calls form.reset(...) again. This also recreates the CodeMirror document and moves the caret to line 1.

Proposed fix

Use api.useUtils() in ShowEnvironment and make saving mutation-safe:

1. await utils.application.one.cancel({ applicationId }) before the mutation, so an in-flight poll cannot overwrite post-save state.
2. On success, update the cached application.one record with saved environment fields via utils.application.one.setData(...).
3. Reset the form from that committed value, then invalidate/refetch for eventual server reconciliation.
4. Add a regression test where a stale poll resolves after saveEnvironment; it must not replace the committed editor value or reset caret position.

Environment

• Dokploy: v0.30.5
• Deployment: self-hosted, same server as Dokploy
• Resource: Application, Dockerfile build

Will you send a PR to fix it?

Yes

Start in apps/dokploy/pages/dashboard/project/[projectId]/environment/[environmentId]/services/application/[applicationId].tsx and trace ShowEnvironment’s application.one polling and saveEnvironment mutation. Add a regression test where a stale poll resolves after saving; done means the committed editor text and caret/scroll position remain unchanged, while the cache is reconciled with the backend.