astarte-platform / astarte_core Goto Github PK

The following endpoints are conflicting, but Astarte doesn't mark them as such:

• /some/%{param}
• /some/thing/here

They should be marked as overlapping since Astarte doesn't allow an endpoint that is a prefix of another one to be in the same interface, as it is reserved to be used to retrieve the endpoints collection (e.g. /some/thing and /some/thing/here are overlapping).

e.g. The following configuration: /some/thing/here, /some/thing/there, /some/thing/somewhere would return:

{
  "here": 1,
  "there": 2,
  "shomewhere": 42
}

Astarte is not reporting them as invalid but an error should be reported instead.

Users should be aware of this and avoid to add similar endpoint configurations to the their interfaces, since the behavior will be fixed in future Astarte releases.

Events sometimes contain an empty BSON document (e.g. %IncomingDataEvent{} when triggered by an unset message). These are not correctly handled by Astarte.Core.Triggers.SimpleEvents.Encoder and this results, for example, in a failure when TriggerEngine tries to serialize such an event.

I was wondering if is there a default ttl when using the use_ttl database rentention policy?

I tried generating a malformed interface with the policy set to use_ttl but missing the ttl field. Inserting it with astartectl wasn't a problem and the interface returned without the ttl.

{
  "interface_name": "com.Int",
  "version_major": 0,
  "version_minor": 1,
  "type": "datastream",
  "ownership": "device",
  "aggregation": "individual",
  "mappings": [
    {
      "endpoint": "/fooo",
      "type": "double",
      "reliability": "unreliable",
      "retention": "discard",
      "database_retention_policy": "use_ttl",
      "explicit_timestamp": true
    }
  ]
}

Here doesn't seem to check for the null value https://github.com/astarte-platform/astarte_core/blob/master/lib/astarte_core/mapping.ex#L227

• Maximum number of allowed endpoint components
• Maximum number of allowed endpoint parameters
• Endpoint maximum length

When a BSON map containing well-formed binary values, e.g. <<18, 0, 0, 0, 5, 118, 0, 5, 0, 0, 0, 0, 1, 2, 3, 4, 5, 0>>, is passed to Cyanide 2.0 decode/1 (resulting in %{"v" => %Cyanide.Binary{subtype: :generic, data: <<1, 2, 3, 4, 5>>}} and then to Astarte.Core.Mapping.ValueType.validate_value/1, the function returns {:error, :unexpected_value_type} instead of the correct :ok.
This happens because the function body pattern-matches on the tuple {_subtype, bin} rather than on a %Cyanide.Binary{} struct, see here:

1. Travis CI cleanup (release-0.10, on Github)

• Use implicit env matrix instead of matrix.include
• Add caching for deps and _build directories
• Move mix coveralls.travis to script instead of after_script

2. Gitlab CI cleanup (release-0.10, on Gitlab)

• Cache deps directory using $CI_COMMIT_REF_SLUG cache key
• test stage, consisting of 1 job:
• mix:test-coverage: runs mix coveralls.details

3. Gitlab CI cleanup (master, on Gitlab)

• Add mix format --check-formatted to test-coverage
• Add dialyzex dep and configure it to use local directory for PLTs in ci env
• Add the PLTs directory to cached paths
• Add mix:test-dialyzer job to test stage, runs mix dialyzer in ci env.

4. Travis CI cleanup (master, on Github)

• Add mix format --check-formatted so that it runs for external contributions

Interface name validation should allow names such as org.astarte-platform.InterfaceName.

Right now, external Elixir applications are able to correctly validate Astarte Interfaces using the changesets contained in Astarte Core.

However, they are not able to do this with Triggers because the top Trigger changeset lives in Astarte Realm Management. This should be moved here so that it can be reused for, e.g., API clients installing triggers and so on.

It should return an error instead.

Minimal failing example:

Astarte.Core.Interface.changeset(%Astarte.Core.Interface{}, %{mappings: [%{"type" => "double"}]})

Currently, if a mapping contains

[...]
"database_retention_policy": "no_ttl",
"database_retention_ttl": 0,
[...]

the Interface validation fails since the TTL must be >= 60, but with a no_ttl policy the TTL isn't actually going to be used. We should decide how to handle this situation, either returning an error if a mapping uses no_ttl and sets a TTL or by silently ignoring the TTL if no_ttl is used (setting it to nil in the changeset function).