Add notification subscription support to CLI

[Matovidlo]

Summary

Implements full notification subscription support in the CLI, enabling users to manage Keboola notification subscriptions as code alongside their configurations.

• Load notifications from API and save to local files
• Push: create/delete subscriptions on remote (modify = delete + create, no update API)
• Track subscriptions in manifest with API-assigned IDs
• Full pull/push/diff workflow with E2E tests

File Structure

{config}/
├── config.json
├── meta.json
└── notifications/
    └── sub-alert/
        └── meta.json     # event, filters, recipient

Manifest Format

{
  "notifications": [
    {"id": "%API_ASSIGNED_ID%", "path": "notifications/sub-alert"}
  ]
}

Key Design Decisions

1. Parent tracking via filters: The API does not return a parent config reference in subscription responses — parent config is inferred from the job.configuration.id filter (auto-populated on push).
2. No-update pattern: Notification API has no update endpoint; CLI handles delete + create transparently.
3. Auto-populated filters: branch.id, job.component.id, job.configuration.id are injected automatically from the parent config context; user-defined filters are merged in.

E2E Tests

• push/notifications-create — create a new notification
• push/notifications-update — update (delete + create) an existing notification
• push/notifications-delete — delete a notification
• push/notifications-create-with-filters — create with user-defined filters

Dependencies

Uses SDK with notification support:
github.com/keboola/keboola-sdk-go/v2 v2.12.1-0.20260223100110-432345f77343

A tagged SDK release should be used once available.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR attempts to add notification subscription support to the Keboola CLI, enabling users to manage notification subscriptions as code. The implementation includes model objects, mappers for local file operations, remote API integration, and documentation.

Changes:

• Adds notification domain model with key, state, and manifest types
• Implements local load/save mappers for notification meta.json files
• Adds remote operations for loading, creating, and deleting notifications via SDK
• Integrates notifications into registry and state management
• Adds comprehensive documentation (253 lines)

Reviewed changes

Copilot reviewed 24 out of 26 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
internal/pkg/model/keys.go	Adds NotificationKey type with Level=4, parent=ConfigKey
internal/pkg/model/keys_test.go	Unit tests for NotificationKey methods
internal/pkg/model/notification.go	Notification domain model with Event, Filters, Recipient, ExpiresAt fields
internal/pkg/model/notificationstate.go	ObjectState implementation for notifications (139 lines)
internal/pkg/model/notificationmanifest.go	Manifest record type for notifications
internal/pkg/model/manifest.go	Adds Notifications slice to ConfigManifest
internal/pkg/model/object.go	Adds NotificationsFrom methods to ObjectStates/Objects interfaces
internal/pkg/mapper/notification/notification.go	Base mapper struct
internal/pkg/mapper/notification/local_save.go	Creates notifications/{id}/meta.json files
internal/pkg/mapper/notification/local_load.go	Loads notifications from filesystem subdirectories
internal/pkg/state/remote/notification.go	Remote load/create/delete operations
internal/pkg/state/remote/manager.go	Integrates notification special handling and loadNotifications call
internal/pkg/state/registry/registry.go	Adds Notifications/NotificationsFrom query methods
internal/pkg/state/registry/proxy.go	Adds NotificationsFrom with state type filtering
internal/pkg/state/manifest/records.go	Handles NotificationKey in CreateOrGetRecord
internal/pkg/project/mappers.go	Registers notification mapper
internal/pkg/service/cli/docs/notifications.md	253-line user documentation
internal/pkg/service/cli/CLI_CONTEXT.md	Quick reference section for notifications
go.mod, go.sum	Updates SDK to pseudo-version with notification support
test/cli/pull/notifications/pull-config-level/*	E2E test files for pull operation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[claude]

Review: Add notification subscription support to CLI

The feature design is solid — the pull/push/diff lifecycle is well-thought-out, the documentation (CLI_OBJECT_LIFECYCLE.md) is excellent, and the mapper/state patterns are consistent with the existing codebase. A few issues need to be addressed before this is ready to merge.

---

Blockers

1. Compile error in retry_test.go (see inline comment)
new(utctime.MustParse(...)) is invalid Go — new takes a type, not a value expression. This breaks compilation of an unrelated test file. Revert to ptr.Ptr(utctime.MustParse(...)).

2. Pseudo-version SDK dependency (see inline comment on go.mod)
The PR uses v2.12.1-0.20260224141819-0b0f6e9b37d3, a pseudo-version. CLAUDE.md explicitly prohibits this. A tagged SDK release must be available before this PR is merged.

---

Bugs

3. Filter operator not checked when matching parent config
In loadNotifications(), the code matches a subscription to its parent config by checking filter.Field == "job.configuration.id" without checking filter.Operator. A subscription with job.configuration.id != "my-config" (not-equals) would be incorrectly attributed to config my-config. See inline comment on remote/notification.go.

4. ValidateNotificationFilters is dead code
The validation function is only called from its own test file — it is never invoked during push, pull, or local-load operations. Users with invalid filter field names will only discover the problem via the API's 400 response, which is caught by the less helpful string-matching error handler. The filter validation should be wired into the actual operation path (e.g., called from the local load mapper or from a Validate() hook on the notification model).

5. Potential duplicate filters on push
After the first push, the API filters (including the auto-populated job.configuration.id) are written back to the local config.json. On a subsequent push, createNotificationRequest() prepends those same fields as auto-filters and then appends notification.Filters (which already contains them), resulting in duplicate filters being sent to the API. Add a deduplication step (skip auto-filters whose field already appears in notification.Filters). See inline comment.

---

Code quality

6. Non-deterministic findSimilarFieldNames output
The function iterates over deprecatedNotificationFilterFieldNames() (a map) without sorting, violating the project convention: "When iterating over maps, always sort results before output." This makes error message suggestions non-deterministic. See inline comment.

7. Repeated allocation of validation helpers
validNotificationFilterFields() and deprecatedNotificationFilterFieldNames() create a new slice/map on every call. They are called multiple times per validation invocation. Promote them to package-level var declarations. See inline comment.

8. Fragile HTTP error detection
The WithOnError callback uses strings.Contains(errMsg, "400") to detect HTTP 400 errors. The literal "400" can appear in notification IDs, config IDs, or filter values in the error message, causing false positives. Prefer checking the error's status code directly (if the SDK exposes it). See inline comment.

9. Path construction duplicated between manifest/file.go and the naming generator
The backwards-compatibility fallback in records() constructs a path with fmt.Sprintf("notifications/sub-%s", notification.ID), duplicating the same format string that lives in Generator.NotificationPath(). See inline comment.

[Copilot]

Pull request overview

Copilot reviewed 96 out of 167 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jachym-tousek-keboola]

these ascii art boxes look a bit malformed, do we need them?

and do we need this document? if yes, does it need to be so long?

[jachym-tousek-keboola]

Nothing looks immediately suspicious except the super long AI generated documents. But this is quite a bit outside of my area of expertise to be honest.