Synth error handling #1502

2024-11-26T04:53:29+08:00

Shpigford commented

2024-11-26 04:53:29 +08:00

(Migrated from github.com)

No description provided.

Shpigford commented

2024-11-26 04:53:48 +08:00

(Migrated from github.com)

@zachgoll Not sure if I'm using the error stuff correctly. Mind taking a look?

zachgoll commented

2024-11-26 05:49:21 +08:00

(Migrated from github.com)

@Shpigford to get this working, there are a few additional steps:

First, we'll need to implement the stale? method on the issue:

class Issue::SynthLimitExceeded < Issue
  include Providable # Give this class access to our configured Synth Provider

  def title
    "Synth API Credit Limit Exceeded"
  end
 
  # Required so our app knows if the error is still happening after the user has taken some action to fix it
  def stale?
    self.class.synth_provider.usage.utilization < 1
  end 
end

Then, we need to add a method in issuable.rb to observe this error:

# app/models/concerns/issuable.rb

def observe_synth_credits_overage
  observe_issue(Issue::SynthLimitExceeded.new)
end

And finally, we need to call account.observe_synth_credits_overage during the account sync process:

class Account
   include Providable 

   def sync_data(start_date: nil)
    update!(last_synced_at: Time.current)

    resolve_stale_issues

    # Observe issue if credits are over limit
    if self.class.synth_provider.usage.utilization >= 1
      observe_synth_credits_overage
    end

    Balance::Syncer.new(self, start_date: start_date).run
    Holding::Syncer.new(self, start_date: start_date).run
  end
end

Simpler solution

I think given this use case, there are probably some simplifications that could be made to the "issues" flow and the Provider::Synth to make all of that more seamless (I can circle back to this after I get investment syncs squared away).

In the meantime, a simpler solution would be to add a convenience method on Family and then conditionally show some alert message somewhere in the UI when they are over the limit:

class Family 
  include Providable 

  def synth_overage?
    self.class.synth_provider && self.class.synth_provider.usage.utilization >= 1
  end
end

<% if Current.family.synth_overage? %> 
  <div>Some alert to user!!!</div>
<% end %>

@Shpigford to get this working, there are a few additional steps: First, we'll need to implement the `stale?` method on the issue: ```ruby class Issue::SynthLimitExceeded < Issue include Providable # Give this class access to our configured Synth Provider def title "Synth API Credit Limit Exceeded" end # Required so our app knows if the error is still happening after the user has taken some action to fix it def stale? self.class.synth_provider.usage.utilization < 1 end end ``` Then, we need to add a method in `issuable.rb` to observe this error: ```ruby # app/models/concerns/issuable.rb def observe_synth_credits_overage observe_issue(Issue::SynthLimitExceeded.new) end ``` And finally, we need to call `account.observe_synth_credits_overage` during the account sync process: ```ruby class Account include Providable def sync_data(start_date: nil) update!(last_synced_at: Time.current) resolve_stale_issues # Observe issue if credits are over limit if self.class.synth_provider.usage.utilization >= 1 observe_synth_credits_overage end Balance::Syncer.new(self, start_date: start_date).run Holding::Syncer.new(self, start_date: start_date).run end end ``` **Simpler solution** I think given this use case, there are probably some simplifications that could be made to the "issues" flow and the `Provider::Synth` to make all of that more seamless (I can circle back to this after I get investment syncs squared away). In the meantime, a simpler solution would be to add a convenience method on `Family` and then conditionally show some alert message somewhere in the UI when they are over the limit: ```ruby class Family include Providable def synth_overage? self.class.synth_provider && self.class.synth_provider.usage.utilization >= 1 end end ``` ```erb <% if Current.family.synth_overage? %> <div>Some alert to user!!!</div> <% end %> ```

Shpigford commented

2024-11-26 05:51:00 +08:00

(Migrated from github.com)

@zachgoll I definitely prefer the simple approach. 🙂 Will get that swapped out and have you review in a bit.

zachgoll commented

2024-11-26 05:54:30 +08:00

(Migrated from github.com)

@Shpigford yeah I agree. Longer term, I think we will basically have 1 single Issue::SynthIssue < Issue that will cover all the possible Synth errors and provide UIs for dealing with them, but for now it definitely needs some fine-tuning to avoid adding a bunch of unnecessary complexity

@Shpigford yeah I agree. Longer term, I think we will basically have 1 single `Issue::SynthIssue < Issue` that will cover _all_ the possible Synth errors and provide UIs for dealing with them, but for now it definitely needs some fine-tuning to avoid adding a bunch of unnecessary complexity

Shpigford commented

2024-11-26 21:38:54 +08:00

(Migrated from github.com)

@zachgoll Mind taking a look at this version?

zachgoll (Migrated from github.com) approved these changes 2024-11-26 21:43:59 +08:00

zachgoll (Migrated from github.com) left a comment

Yep, looks good

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gavin/maybe#1502