Overcharged consistently for creating a new thing - Conditionals to Secure WF

this is a formatted list of some of my text based remarks…

  • Inconsistent Data Requests:
    • Variable number of individual data requests across similar tests (e.g., 3, 4, or 5 requests) despite identical conditions.
    • Unexpected increase in data requests when conditions are placed on actions versus event triggers.
  • Variable Work Unit (WU) Costs:
    • Creating a “Broker” consistently incurs higher WU costs (2.12 WU) compared to other “create new thing” actions (0.62 WU).
    • Discrepancies in WU charges for similar actions, such as “create a new blog post” costing 1.43 WU versus expected totals.
  • Unexpected Conditional Evaluation Charges:
    • Some tests show unexpected charges for condition evaluations (e.g., 0.32 WU) while identical conditions in other tests do not incur these charges.
    • Inconsistent application of conditional evaluation charges, leading to confusion over when and why they are applied.
  • Search Charge Anomalies:
    • Expected search charges (e.g., 0.3 WU) were missing in certain tests, especially when users were not logged in.
    • Conditions requiring searches do not consistently trigger the expected data fetch charges.
  • Workflow vs. Data Fetching Charges:
    • Charges are sometimes labeled as “workflow” instead of specific actions like data fetching or conditional evaluations, causing ambiguity.
    • Inconsistent labeling leads to difficulty in tracking and understanding charge sources.
  • Ghost Bar Scenarios:
    • Certain actions (e.g., at timestamps 1:54, 1:56, 4:52) show no associated charges, indicating that conditions or searches may not have been performed.
  • Differences Based on User Authentication:
    • Logged-out users trigger different charge patterns, such as workflow charges combined with individual data request charges, compared to logged-in users.
    • Authentication status affects how conditions and actions are evaluated and billed.
  • Charge Calculation Discrepancies:
    • Total WU charges for actions (e.g., 1.12 WU for create) do not align with expected sums based on individual component charges (e.g., 0.62 WU for create + 0.3 WU for search = 0.92 WU).
    • Inconsistent charge totals across similar actions make it difficult to predict billing accurately.
  • Inconsistent Labeling of Charges:
    • Charges related to conditional evaluations and data fetching are labeled inconsistently, sometimes under “workflow” instead of their specific action types.
    • This inconsistency complicates the identification and understanding of charge sources.
  • Conditions on Event Triggers:
    • Placing conditions on event triggers results in different and often unexpected behavior compared to placing conditions directly on actions.
    • Server-side evaluations on event triggers do not consistently align with expected charge patterns.
  • Workflow Charge Variations Across Runs:
    • Subsequent runs of similar workflows exhibit different charge applications, such as the first run having only a workflow charge and the second run adding data request charges.
    • Variability between workflow executions complicates charge predictability and consistency.

I created these tests as I put up a post on conditions and security and some other users were adamant there are no issues and everything works as expected. Unfortunately, testing yields pretty much exactly the opposite.

4 Likes