fix: document cron router auth chain
This commit is contained in:
Naeel
@@ -0,0 +1,159 @@
|
||||
# GPT 5.4 handoff: Fission CRON plan
|
||||
|
||||
## Goal
|
||||
|
||||
Составить только план действий по теме Fission cron / time triggers. Не писать реализацию сейчас. Не раздувать ответ. Нужен прагматичный, короткий, пошаговый план.
|
||||
|
||||
## What is the topic
|
||||
|
||||
В Fission cron-триггеры в документации и CRD называются `TimeTrigger`, а в CLI — `fission timetrigger`.
|
||||
|
||||
## Official docs used as source of truth
|
||||
|
||||
- https://fission.io/docs/usage/triggers/
|
||||
- https://fission.io/docs/usage/triggers/timer/
|
||||
- https://fission.io/docs/reference/crd-reference/
|
||||
- https://fission.io/docs/reference/fission-cli/fission_timetrigger/
|
||||
- https://fission.io/docs/reference/fission-cli/fission_timetrigger_create/
|
||||
- https://fission.io/docs/reference/fission-cli/fission_timetrigger_showschedule/
|
||||
|
||||
## Facts to keep in mind
|
||||
|
||||
- There is no dedicated `/docs/cron/` page on the official site; relevant official page is `Timer Triggers`.
|
||||
- Timer triggers run functions on a schedule.
|
||||
- Cron spec supports 6 fields: seconds, minutes, hours, day of month, month, day of week.
|
||||
- Readable forms are supported too: `@every 5m`, `@hourly`.
|
||||
- Schedule output should use server time, not client time.
|
||||
|
||||
## CRD facts
|
||||
|
||||
- `apiVersion`: `fission.io/v1`
|
||||
- `kind`: `TimeTrigger`
|
||||
- `spec.cron` — cron expression
|
||||
- `spec.functionref` — function reference
|
||||
- `spec.method` — HTTP method, default `POST`
|
||||
- `spec.subpath` — subpath, default `/`
|
||||
- `functionref.type` is `name`
|
||||
- `functionref.name` is the function name
|
||||
|
||||
## CLI facts
|
||||
|
||||
### `fission timetrigger`
|
||||
Subcommands from official docs:
|
||||
- `create`
|
||||
- `delete`
|
||||
- `list`
|
||||
- `showschedule`
|
||||
- `update`
|
||||
|
||||
### `fission timetrigger create`
|
||||
Key flags:
|
||||
- `--name`
|
||||
- `--function`
|
||||
- `--cron`
|
||||
- `--method`
|
||||
- `--subpath`
|
||||
- `--spec`
|
||||
- `--dry`
|
||||
|
||||
### `fission timetrigger showschedule`
|
||||
Key flags:
|
||||
- `--cron`
|
||||
- `--round`
|
||||
|
||||
## Repo facts
|
||||
|
||||
Current repo has a local CRON folder with:
|
||||
- `CRON/README.md`
|
||||
- `CRON/CLI.md`
|
||||
- `CRON/CRD.md`
|
||||
- `CRON/EXAMPLES.md`
|
||||
- `CRON/GLOSSARY.md`
|
||||
|
||||
Relevant console routes currently visible in code:
|
||||
- `GET /api/timetriggers`
|
||||
- `GET /console/api/timetriggers`
|
||||
|
||||
This means current console code clearly exposes listing for timetriggers; do not assume create/delete UI is already implemented unless verified separately.
|
||||
|
||||
## What the plan should optimize for
|
||||
|
||||
- shortest path to useful outcome
|
||||
- no token waste
|
||||
- no speculative implementation details
|
||||
- only actions that are justified by the facts above
|
||||
|
||||
## Recommended output format for GPT 5.4
|
||||
|
||||
1. One-line conclusion
|
||||
2. Short numbered plan
|
||||
3. Risks or unknowns, only if they block the plan
|
||||
4. No extra explanation
|
||||
|
||||
## Plan for mini
|
||||
|
||||
1. Зафиксировать целевой результат: что именно нужно сделать с cron в этом проекте.
|
||||
Нужно выбрать одно из трёх:
|
||||
`документация`, `console API CRUD`, `UI CRUD/просмотр`, либо полный путь поэтапно.
|
||||
|
||||
2. Принять официальный термин как базовый.
|
||||
В коде и плане опираться на `TimeTrigger`/`timetrigger`, а не на абстрактное “cron”, чтобы не путать CLI, CRD и UI.
|
||||
|
||||
3. Разделить текущее состояние на “уже есть” и “надо сделать”.
|
||||
Уже есть:
|
||||
`официальная сводка`, `CRON docs`, `GET /api/timetriggers`, `GET /console/api/timetriggers`.
|
||||
Проверить отдельно:
|
||||
есть ли `POST/DELETE/UPDATE` для timetriggers в console API, модель запроса, UI-форма, UI-delete.
|
||||
|
||||
4. Если цель именно реализация, сначала закрыть backend API.
|
||||
Минимальный набор:
|
||||
`CreateTimeTriggerRequest`,
|
||||
`POST /console/api/timetriggers`,
|
||||
`DELETE /console/api/timetriggers/:name`,
|
||||
при необходимости `PUT`.
|
||||
Логика должна строить CRD `fission.io/v1`, `kind: TimeTrigger` с полями:
|
||||
`cron`, `functionref`, `method`, `subpath`.
|
||||
|
||||
5. После backend закрыть валидацию.
|
||||
Нужно валидировать:
|
||||
имя,
|
||||
существование функции,
|
||||
непустой `cron`,
|
||||
при необходимости `method`,
|
||||
дефолты для `method=POST`, `subpath=/`.
|
||||
Отдельно не гадать формат cron вручную, если можно отдать это на Fission/его контракт.
|
||||
|
||||
6. Затем делать UI только после подтверждённого backend.
|
||||
Минимум:
|
||||
список timetriggers,
|
||||
создание,
|
||||
удаление,
|
||||
опционально редактирование.
|
||||
Если UI не нужен сейчас, не тратить на него время.
|
||||
|
||||
7. Тестировать в том же порядке.
|
||||
Сначала unit/integration на API builder TimeTrigger.
|
||||
Потом живой сценарий:
|
||||
создать функцию,
|
||||
создать timetrigger,
|
||||
проверить list,
|
||||
проверить delete.
|
||||
`showschedule` использовать как вспомогательную проверку cron-строк, а не как часть console API.
|
||||
|
||||
8. Документацию держать синхронно с реализацией.
|
||||
Обновлять только новую папку CRON и соседние материалы, не размазывая контекст по старым документам без необходимости.
|
||||
|
||||
9. Не делать лишнего на первом проходе.
|
||||
Не трогать:
|
||||
Terraform provider,
|
||||
сложный scheduler,
|
||||
расширенные cron-валидаторы,
|
||||
полный UI-редизайн,
|
||||
пока не готов минимальный CRUD по TimeTrigger.
|
||||
|
||||
10. Рабочий порядок для mini:
|
||||
сначала поиск фактов в коде,
|
||||
потом backend routes/models/handlers,
|
||||
потом тесты,
|
||||
потом UI,
|
||||
потом короткая проверка живым сценарием.
|
||||
Reference in New Issue
Block a user