1
0
mirror of https://github.com/Unleash/unleash.git synced 2024-11-01 19:07:38 +01:00
Commit Graph

3 Commits

Author SHA1 Message Date
Thomas Heartman
7ea4e5d5b9
chore: remove additionalProperterties: true annotation. (#4508)
Unless you set `additionalProperties` to `false`, additional properties
are always
allowed. By explicitly setting it to `true` the generated
examples contain additional properties, e.g.:

```json
{
  "tokens": [
    "aproject:development.randomstring",
    "[]:production.randomstring"
  ],
  "additionalProp1": {}
}
```

By removing the explicit annotation, we still allow additional
properties, but we don't get them in examples:

```json
{
  "tokens": [
    "aproject:development.randomstring",
    "[]:production.randomstring"
  ]
}
```
2023-08-16 11:17:05 +02:00
Gastón Fournier
4e0678dfb1
fix: allow empty appName as it may come in the url (#3953)
## About the changes
Edit application under
https://app.unleash-hosted.com/demo/applications/test-app is currently
not working as the appName is expected to come in the request body, but
it's actually part of the url. We have two options here:
1. We change the UI to adapt to the expectations of the request by
adding appName to the request body (and eventually removing appName from
the URL, which would be a breaking change)
2. We remove the restriction of only sending the appName in the body and
take the one that comes in the URL. We have a validation that verifies
that at least one of the two sets the appName
([here](e376088668/src/lib/services/client-metrics/instance-service.ts (L208))
we validate using [this
schema](e376088668/src/lib/services/client-metrics/schema.ts (L55-L70)))

In terms of REST API, we can assume that the appName will be present in
the resource `/api/admin/metrics/applications` (an endpoint we don't
have), but when we're updating an application we should refer to that
application by its URL: `/api/admin/metrics/applications/<appName>` and
the presence of an appName in the body might indicate that we're trying
to change the name of the application (something we currently not
support)

Based on the above, I believe going with the second option is best, as
it adheres to REST principles and does not require a breaking change.
Despite that, we only support updating applications as the creation is
done from metrics ingestion

Fixes: #3580
2023-06-12 10:15:00 +02:00
Christopher Kolstad
1b248a03e9
docs: Metrics tag openapi docs (#3572)
I've copied most of the descriptions from what we did for batch metrics
under the Edge tag, however there are a couple of top level descriptions
that are "fine" but I'm definitely open to suggestions.

---------

Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
2023-04-26 12:10:57 +02:00