Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

baermat
Copy link
Member

@baermat baermat commented Sep 4, 2025

PNX-76

Motivation

First step towards creating the new SNS provider. Since subscribe/unsubscribe already almost exclusively lived in LocalStack, this seemed like a good fit. However, subscribe is somewhat coupled with publish, and subscribe tests rely on topics. Implementing topics in LocalStack and porting publish operations are therefore the next steps, so we can also start enabling tests.

Code is moved on a need basis. As a result, publisher.py was ported to a degree, but is for now not really usable. This will be addressed in a follow up PR.

Both certificate.py as well as executor.py were not copied but directly referenced. Neither have moto dependencies, and due to their size and function they are unlikely to change during this project.

Changes

  • add constanty.py for v2 (which also includes a constant for a util function from moto)
  • add filter.py for v2 (which is identical to v1)
  • add more models
  • add subscribe/unsubscribe to provider.py
    • remove moto calls, which is a temporary loss of functionality because the resources are not yet implemented. All such instances are marked with TODOs
  • add utils.py that gathers all utility functions that accumulated in the provider over the years, similar to sqs.

TODO

What's left to do:

  • Clarify filter.py if it should be copied or referenced

@baermat baermat force-pushed the sns/v2-verify-subscribe-operations branch from e757333 to 405007e Compare September 4, 2025 12:48
@baermat baermat added semver: minor Non-breaking changes which can be included in minor releases, but not in patch releases skip-docs Pull request does not require documentation changes labels Sep 4, 2025
@baermat baermat self-assigned this Sep 4, 2025
@baermat baermat added this to the Playground milestone Sep 4, 2025
Copy link

github-actions bot commented Sep 4, 2025

Test Results - Preflight, Unit

22 117 tests  ±0   20 379 ✅ ±0   6m 26s ⏱️ +2s
     1 suites ±0    1 738 💤 ±0 
     1 files   ±0        0 ❌ ±0 

Results for commit 555f58d. ± Comparison against base commit 445c32f.

♻️ This comment has been updated with latest results.

@@ -0,0 +1,538 @@
import ipaddress
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is identical to v1 filter.py. I am not sure if this is the correct approach: on the one hand, this might need changing when implementing v2 operations. On the other hand, there are no changes right now, which means any potential change in v1 upstream will have to be copied here, and might get overlooked.

Copy link

github-actions bot commented Sep 4, 2025

Test Results (amd64) - Acceptance

7 tests  ±0   5 ✅ ±0   3m 19s ⏱️ +9s
1 suites ±0   2 💤 ±0 
1 files   ±0   0 ❌ ±0 

Results for commit 555f58d. ± Comparison against base commit 445c32f.

♻️ This comment has been updated with latest results.

Copy link

github-actions bot commented Sep 4, 2025

Test Results (amd64) - Integration, Bootstrap

    5 files      5 suites   1h 29m 36s ⏱️
2 823 tests 2 715 ✅ 108 💤 0 ❌
2 829 runs  2 715 ✅ 114 💤 0 ❌

Results for commit 555f58d.

Copy link

github-actions bot commented Sep 4, 2025

LocalStack Community integration with Pro

    2 files  ±    0      2 suites  ±0   1h 0m 23s ⏱️ - 42m 16s
2 799 tests  - 1 836  2 688 ✅  - 1 504  111 💤  - 332  0 ❌ ±0 
2 801 runs   - 1 836  2 688 ✅  - 1 504  113 💤  - 332  0 ❌ ±0 

Results for commit 555f58d. ± Comparison against base commit 445c32f.

This pull request removes 1836 tests.
tests.aws.scenario.bookstore.test_bookstore.TestBookstoreApplication ‑ test_lambda_dynamodb
tests.aws.scenario.bookstore.test_bookstore.TestBookstoreApplication ‑ test_opensearch_crud
tests.aws.scenario.bookstore.test_bookstore.TestBookstoreApplication ‑ test_search_books
tests.aws.scenario.bookstore.test_bookstore.TestBookstoreApplication ‑ test_setup
tests.aws.scenario.kinesis_firehose.test_kinesis_firehose.TestKinesisFirehoseScenario ‑ test_kinesis_firehose_s3
tests.aws.scenario.lambda_destination.test_lambda_destination_scenario.TestLambdaDestinationScenario ‑ test_destination_sns
tests.aws.scenario.lambda_destination.test_lambda_destination_scenario.TestLambdaDestinationScenario ‑ test_infra
tests.aws.scenario.loan_broker.test_loan_broker.TestLoanBrokerScenario ‑ test_prefill_dynamodb_table
tests.aws.scenario.loan_broker.test_loan_broker.TestLoanBrokerScenario ‑ test_stepfunctions_input_recipient_list[step_function_input0-SUCCEEDED]
tests.aws.scenario.loan_broker.test_loan_broker.TestLoanBrokerScenario ‑ test_stepfunctions_input_recipient_list[step_function_input1-SUCCEEDED]
…

@baermat baermat marked this pull request as ready for review September 5, 2025 07:20
@baermat baermat requested a review from bentsku as a code owner September 5, 2025 07:20
Copy link
Contributor

@bentsku bentsku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice start! I'm not sure I fully understand the logic behind starting with SNS Subscriptions, because we cannot write any tests for it at the moment or validate any of the code of the new provider.

It feels like starting with Topics, at least the CRUD side of it would be the best choice, you could start writing and validating some tests already. As Subscriptions have a hard dependency on topics, it will be easier to first write and validate topics CRUD operations, to then try and validate subscriptions operations.

Implementing all the CRUD operations of Topics should be the first steps, we can keep this PR until then?

I believe that once Topics are migrated, and we start moving over existing Subscription-related code that does not depend on moto, we can see if we need to adapt the v2 store or not, and then decide if we need to copy/paste the current publisher.py or can use the current one for both with very little adaptation. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as filter.py. I don't see a hard dependency on moto here, except the store_delivery_log function which has a little dependency because of the topic_attributes dict casing, but it could handle both case without major changes.

The other issue maybe is the store access: this I can see being an issue, but looking at the current v2 models, they are pretty similar to v1? Except the utility store.get_topic_subscriptions, but the publisher code could be adapted to not rely on it anymore and internalize the logic instead, for both v1 and v2?

Maybe I am missing something, I think the store access could be a bit problematic but I think it'd be cheaper for us to have publisher.py be compatible with both instead of full duplication of code that isn't directly relying on moto, what do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver: minor Non-breaking changes which can be included in minor releases, but not in patch releases skip-docs Pull request does not require documentation changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants