Add tests for receiving and paying invoices when position is open

[klochowicz]

Add test coverage to a ticket that got recently closed - we should test that we can receive and send payments

Also, return error in the API if a payment failed

[klochowicz]

@holzeis it failed again on CI - I think I will add a getter to see open positions and wait_until! there is one on the coordinator.

[holzeis]

@holzeis it failed again on CI - I think I will add a getter to see open positions and wait_until! there is one on the coordinator.

I think that would be useful for many reasons 👍

[klochowicz]

@holzeis it failed again on CI - I think I will add a getter to see open positions and wait_until! there is one on the coordinator.

I think that would be useful for many reasons 👍

I will move that into a follow-up, as I don't want to block anyone else writing e2e tests (I know @da-kami is about to do some)

[klochowicz]

bors r+

[bors]

Canceled.

[klochowicz]

bors r+

[bors]

Build failed:

• e2e-tests

[klochowicz]

bors r+

[bors]

Build failed:

• clippy

[klochowicz]

bors r+

[da-kami]

Build failed:

* [e2e-tests](https://github.com/get10101/10101/actions/runs/5461131629/jobs/9938791983)

Was this test flaky - did you change something?

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• clippy
• e2e-tests
• formatting
• lint-commits
• lint-flutter

[klochowicz]

Build failed:

* [e2e-tests](https://github.com/get10101/10101/actions/runs/5461131629/jobs/9938791983)

Was this test flaky - did you change something?

see your github notifications. it's the JIT payment feature being flaky - there's an open ticket to address it #883

[holzeis]

Build failed:

* [e2e-tests](https://github.com/get10101/10101/actions/runs/5461131629/jobs/9938791983)

Was this test flaky - did you change something?

see your github notifications. it's the JIT payment feature being flaky - there's an open ticket to address it #883

The flaky test has nothing to do with #883 - It's the new test that has been added with that change that failed.

@klochowicz given that the e2e tests are flaky like the "slow running" tests. Should we revert #888 ?

[da-kami]

Build failed:

* [e2e-tests](https://github.com/get10101/10101/actions/runs/5461131629/jobs/9938791983)

Was this test flaky - did you change something?

see your github notifications. it's the JIT payment feature being flaky - there's an open ticket to address it #883

The flaky test has nothing to do with #883 - It's the new test that has been added with that change that failed.

@klochowicz given that the e2e tests are flaky like the "slow running" tests. Should we revert #888 ?

Thanks for pointing this out :)
I would monitor it for a bit and then decide - if they are flaky we can consider reverting, or just improve them.

[klochowicz]

Build failed:

* [e2e-tests](https://github.com/get10101/10101/actions/runs/5461131629/jobs/9938791983)

Was this test flaky - did you change something?

see your github notifications. it's the JIT payment feature being flaky - there's an open ticket to address it #883

The flaky test has nothing to do with #883 - It's the new test that has been added with that change that failed.

@klochowicz given that the e2e tests are flaky like the "slow running" tests. Should we revert #888 ?

IMHO ideally we should make them stable again - which means tidying up recent workarounds etc, and ensuring we always get properly funded.

however, if it gets in the way of development, of course we can disable it on bors.

[holzeis]

The flaky test has nothing to do with #883 - It's the new test that has been added with that change that failed.
@klochowicz given that the e2e tests are flaky like the "slow running" tests. Should we revert #888 ?

IMHO ideally we should make them stable again - which means tidying up recent workarounds etc, and ensuring we always get properly funded.

however, if it gets in the way of development, of course we can disable it on bors.

what workarounds are you referring to? If its the additional mining when funding the app, we might be able to remove that, because of #913. But, that shouldn't have an impact on the flakiness of the tests.. On the contrary, I only added that to remove the flakiness of that test.

[klochowicz]

The flaky test has nothing to do with #883 - It's the new test that has been added with that change that failed.
@klochowicz given that the e2e tests are flaky like the "slow running" tests. Should we revert #888 ?

IMHO ideally we should make them stable again - which means tidying up recent workarounds etc, and ensuring we always get properly funded.
however, if it gets in the way of development, of course we can disable it on bors.

what workarounds are you referring to? If its the additional mining when funding the app, we might be able to remove that, because of #913. But, that shouldn't have an impact on the flakiness of the tests.. On the contrary, I only added that to remove the flakiness of that test.

FWIW, I've never seen any of these tests failing before the PRs with JIT channel fees got merged. This might be of course due to the flakiness of the test, but also it might be that we have a problem in our code.

the other one which we should address, and was referring to was #893 - to exclude the possibility that it's the fault of the just fund (which fails often on some machines).