<p>I had the same issue. Slots are 1 second and cannot be broken down any further. So when you use the <code>slotToEndPOSIXTime def 25</code>, you will get something like 1596059104999. This number is number is in milliseconds, and is not a valid slot because of the trailing 999. You need to add 1 to this number to bump it up to 1596059105000 so that it is evenly divisible by 1000(1000ms/1Second).</p>
<p>I hope that helps!</p>

CC BY-SA 4.0
2021-10-27T14:50:30.470Z
2021-10-27T14:50:30.470Z
Isaac Padberg
<p>I have an issue with <code>Constraints.mustValidateIn</code> in a StateMachine.
In the case using <code>Interval.to deadline</code> everything works as expected. But in the case: <code>Interval.from deadline</code> the constraint is never valid.
I also tried to build the interval by hand to exclude issues with closure: <code>Interval {ivFrom = LowerBound (Finite $ deadline object) False, ivTo = UpperBound PosInf True}</code> Tried with and without closure but it does not have any effect. Also waiting and use the transition in a slot which is far beyond the deadline does not work.</p>
<p>Docs say :</p>
<pre><code> mustValidateIn :: forall i o. POSIXTimeRange -&gt; TxConstraints i o

 *mustValidateIn r requires the transaction's time range to be contained in r.*
</code></pre>
<p>If I understand it correct, in this case it means the transaction have to happen between deadline and infinity, which should be represented by the interval above?</p>
<p>I define the deadline in the trace as : <code>slotToEndPOSIXTime def 25</code></p>
<p>Very confusing is: when I change it to <code>slotToBeginPOSIXTime def 25</code> without changing anything else the behavior turns around...
Anyway my waitForNSlots in the trace are always minimum 3 slots so it should also not run in some limit case.
The actual distance between <code>slotToBeginPOSIXTime</code> and <code>slotToEndPOSIXTime</code> is, if calculated in repl, 999 milliseconds as I would expect with a slot time of 1s.</p>
<p>(Also tried to add / subtract some seconds from the POSIXTime, which had no effect)</p>
<p>Do am I miss something here?</p>
<p>Thank you for support</p>

<slottime><statemachines>
Constraints.mustValidateIn in a StateMachine
# Constraints.mustValidateIn in a StateMachine

(Asked by: username_0 on 2021-09-06)

I have an issue with Constraints.mustValidateIn in a StateMachine.
In the case using Interval.to deadline everything works as expected. But in the case: Interval.from deadline the constraint is never valid.
I also tried to build the interval by hand to exclude issues with closure: Interval {ivFrom = LowerBound (Finite $ deadline object) False, ivTo = UpperBound PosInf True} Tried with and without closure but it does not have any effect. Also waiting and use the transition in a slot which is far beyond the deadline does not work.
Docs say :
 mustValidateIn :: forall i o. POSIXTimeRange -> TxConstraints i o

 *mustValidateIn r requires the transaction's time range to be contained in r.*

If I understand it correct, in this case it means the transaction have to happen between deadline and infinity, which should be represented by the interval above?
I define the deadline in the trace as : slotToEndPOSIXTime def 25
Very confusing is: when I change it to slotToBeginPOSIXTime def 25 without changing anything else the behavior turns around...
Anyway my waitForNSlots in the trace are always minimum 3 slots so it should also not run in some limit case.
The actual distance between slotToBeginPOSIXTime and slotToEndPOSIXTime is, if calculated in repl, 999 milliseconds as I would expect with a slot time of 1s.
(Also tried to add / subtract some seconds from the POSIXTime, which had no effect)
Do am I miss something here?
Thank you for support

**Tags:** slottime, statemachines

---

## 1 answers

### Answer by username_1 on 2021-10-27. Score: 0

I had the same issue. Slots are 1 second and cannot be broken down any further. So when you use the `slotToEndPOSIXTime def 25`, you will get something like 1596059104999. This number is number is in milliseconds, and is not a valid slot because of the trailing 999. You need to add 1 to this number to bump it up to 1596059105000 so that it is evenly divisible by 1000(1000ms/1Second).

I hope that helps!


---

