by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mark Kegel
    @littlenag
    tables are created
    can curl a new entry and I get an appropriate response
    but i see nothing written to the db
    no errors in the logs either, unless i deliberately send malformed json
    Przemek Sokół
    @falconepl
    Do you use DataGrip, by any chance? I've hit a bug in it once that listed all my tables as empty, although they were populated. They were all using default public scheme, as usual
    Mark Kegel
    @littlenag
    @falconepl i do, but i'm also connecting via psql
    both show the tables as empty
    Przemek Sokół
    @falconepl
    I will check with a fresh setup of the ticket booking demo. Hopefully I will be able to reproduce that, but if it's really the case - that would be a nasty bug. DB not being written to, without any errors... Cannot think of anything worse in the case of that demo
    Mark Kegel
    @littlenag
    @falconepl yeah the issue is with my codebase but its based on the ticket booking demo and really only involves so far some minor renaming. when i get a chance i'm going to re-test with the ticket booking codebase itself. i thought that maybe i had messed up the protobuf serialization but a unit test showed that it was working as intended. my guess is that something i did is generating an exception that is being swallowed.
    Przemek Sokół
    @falconepl
    Sure, let us now when you discover something. I couldn't reproduce that myself - events & view were written to my DB as expected. As you've said that might be something related to your codebase & some minor change within the whole setup
    Were you able to observe those missing writes also with vanilla ticket-booking-aecor demo or only with your own project?
    Mark Kegel
    @littlenag
    @falconepl ok, i've tracked the issue down
    the ticket booking demo works just fine, btw
    here is the code in question: ```
      def reserve(client: ClientId, records: NonEmptyList[LnsRecord], expiresAt: Instant): I[Unit] = {
        for {
          now <- currentTime
          x <- OptionT(read).cata(
            if (records.distinct =!= records) reject(DuplicateRecords)
            else if (records.size > 4) reject(TooManyRecords)
            else if (expiresAt.isBefore(now)) reject(InvalidExpirationDate)
            else append(PointCodeReserved(client, records, expiresAt)),
    
            _ => reject(PointCodeAlreadyExists),
          )
        } yield x
      }
    this is my version of EventsourcedBooking.place
    starting out i'm oddly able to re-use nearly everything in the ticket booking example, so i've had to make very few changes
    the only real difference is that i now need the current time
    the issue appears to be related to OptionT(read).cata
    i'm not sure why, but if i remove that part, and just pattern match on the result then i get everything working as normal
    if not, then i get nothing written in the database
    my guess is that the Functor for I that cata needs is some how messed up
    Mark Kegel
    @littlenag
    ok, i see the issue now
    mapping when i should have been flatMapping, which was hidden by the any to Unit + turning off the value discard warning
    plus, cata can't do what i want
    figured the issue out by unrolling what cata does
    Przemek Sokół
    @falconepl
    @littlenag Nice catch! Good to hear that you've tracked down the issue
    Yeah, -Ywarn-value-discard is super helpful, especially when used along with -Xfatal-warnings
    Saved me many times. Debugging value discard related bugs can get pretty nasty sometimes
    Przemek Sokół
    @falconepl
    It's in ticket-booking-aecor's build.sbt already, so I guess you've got your custom build.sbt (at least not a tailored copy-paste from the demo)?
    Mark Kegel
    @littlenag
    @falconepl i disabled fatal warnings, but not warn-value-discard, as i was doing my refactor since that tends to cause lots of noise that is usually irrelevant during most refactorings
    in general i like the auto-unit conversion that scala does
    i do wonder though for when you want effects if it wouldn't make sense to have a separate placeholder, like say Akka does with NotUsed I think it is, for when you really intend to have no action
    an ergonomics + bike shedding issue for sure
    Przemek Sokół
    @falconepl
    @notxcain Is it possible to configure scala-steward so that it creates PRs less frequently (or alters existing PRs), with batched changes, rather than creating a new PR every other day?
    scala-steward is great, but the amount of spam it generates is unbelievable 🙂
    Przemek Sokół
    @falconepl
    Oh, and by the way. I'm currently working on some basic saga support for Aecor and it seems that I will need to make saga's algebra shape as Saga[F[_], D] - and that's because it should provide some create(data: D): F[Unit] capability (every user's concrete saga implementation may operate on a different data type passed around)
    It turns out that kind-projector allows to handle that case even with the existing EventsourcedBehavior, but my question is whether you would consider that an acceptable design at all?
    Przemek Sokół
    @falconepl
    Namely the Saga[F[_], D] shape that will have an existing EventsourcedSaga[F[_], D] implementation, provided by the library out of the box, and the only thing that the user cares about is to specify the saga's flow (and wire everything, of course), with some DSL such as:
    step {
      attempt { data =>
        // we call some specific entity:
        warehouses(...).markForDeparture(...)
      }
      .handleFailWith { data =>
        warehouses(...).cancelDeparture(...)
      }
      .commitWith { data =>
        warehouses(...).issueGoods(...)
      }
      // both handleFailWith and commitWith are optional
    }
    .step {
      attempt { data =>
        shops(...).reserveSpace(...)
      }
      // (...)
    }
    Gunnar Lilleaasen
    @heksesang
    @falconepl How is the work going with the saga-feature? :)
    Przemek Sokół
    @falconepl
    @heksesang I haven't been working on it recently, quite frankly. I've got a few doubts when it comes to saga's design in Aecor - wanted to discuss that with Denis first, but it seems that he's not available on Gitter that often (I remember he's mentioned to be quite busy these days)
    Gunnar Lilleaasen
    @heksesang
    I’d love to see it added. But you don’t think it’s viable?
    Gunnar Lilleaasen
    @heksesang
    Do you have any code so far I could look at?
    Przemek Sokół
    @falconepl
    The thing is that the whole saga mechanics is based on EventsourcedBehavior, as Denis once suggested, but the whole interaction with it might feel a bit hacky, I would say...? And that's because EventsourcedBehavior wasn't introduced with Saga[F[_], D] shape in mind, obviously. I'm not entirely sure whether the final version done this way could end up being merged into the Aecor's master, as it might not fit the rest of library's "zen". I haven't pushed the current POC to my fork, as it still requires major clean-up
    Gunnar Lilleaasen
    @heksesang
    Well, maybe make saga as an alternative rather than building it on top of it then? That could be a solution?
    Przemek Sokół
    @falconepl
    The whole Aecor, when it comes to behavior execution on top of Akka and its event-sourcing support, comes down to those traits and classes revolving around T[F[_]] algebras and EventsourcedBehavior, so it seems that reusing existing blocks should be the way to go - possibly with some tweaks here and there. The alternative would carry much more work to be done. Anyhow, I would rather discuss saga's design premises before raising any PR
    Gunnar Lilleaasen
    @heksesang
    But for a Saga[F[_], D], what exactly is the D type in the design you imagined?
    Przemek Sokół
    @falconepl
    One could use saga pattern in Aecor right now - you just need to create bunch of entities and processes. My approach was to minimize the amount of boilerplate needed to encode saga's flow as well as provide transitions mechanics out of the box, so that the end user doesn't need to worry about it. Generally speaking, the only thing that needs to be defined by the user is the saga's flow DSL (as in my snippet above). This way the main saga logic (provided by the library) has to be as generic as possible. Thus the D type parameter in question, that represents any data type that the particular saga operates on. It's data type from the DSL snippet
    Dan Di Spaltro
    @dispalt
    @notxcain is there a way with the E2E testing to actually wire up the firing of ScheduledEntries?
    Dan Di Spaltro
    @dispalt
    @notxcain I feel like you could compete with https://github.com/uber/cadence/ if you combined your scheduling stuff and extended the ActionT runtime to have more functionality (like some native events on top of serialized events)