serverless-ide-vscode
serverless-ide-vscode copied to clipboard
"Unexpected property destinations" when setting failure destinations for kinesis streams
-
I'm submitting a ...
- [x] bug report
- [ ] feature request
- [ ] support request => Please do not submit support request here, see note at the top of this template.
-
Do you want to request a feature or report a bug? Report a bug
-
What is the current behaviour? When using serverless framework kinesis streams destinations Serverless IDE reports an unexpected property.
-
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar.
Code (copied from the above documentation link):
functions:
preprocess2:
handler: handler.preprocess
events:
- stream:
arn: arn:aws:kinesis:region:XXXXXX:stream/foo
batchSize: 100
maximumRetryAttempts: 10
startingPosition: LATEST
enabled: false
destinations:
onFailure:
arn:
Fn::GetAtt:
- MyQueue
- Arn
type: sqs
The IDE:
- What is the expected behaviour?
As this is clearly a supported feature of serverless, I would not expect the serverless IDE to generate an error for this setup
- What is the motivation / use case for changing the behavior?
As above
-
Please tell us about your environment:
- Plugin version
- Serverless IDE v0.5.34
- VSCode version
- Version: 1.69.0 (Universal)
- Template type
- YAML, serverless lambda
- Plugin version
I think this might a schema issue for serverless. @pavelvlasov I noticed you have your own schema for serverless. You could use the one from schema store.
Hey @KillDozerX2! Thanks for the suggestion. Unfortunately using schema from the schema store would break inline documentation. I'm thinking in favor of removing validation from future releases, as I don't have enough resources to maintain it in a good shape and just keep and autocomplete / documentation part.
Anyway, the issue should be resolved in the next release.
if you want, I can maintain a fork for serverless framework. But would require some knowledge transfer.
@KillDozerX2 that's not a bad idea 👍 It would require adding a "description" field to the entities in the schema, like here (maybe even extending the existing one instead of the fork) and making sure the new schema does not break anything in the plugin logic.
I actually maintain the schema, so it should be okay for me to do it. I will look into what you suggested. Thanks
@KillDozerX2 awesome! Let me know if you made any progress on it and, I can check if the change of the schema does not break anything.