Modify test suite to precisely verify that only the nodes specified in rootOperations are changed

Reference: https://github.com/SpoonLabs/diffmin/pull/65#pullrequestreview-665487907
I tried to modify the test suite however it is coming off as a really difficult task. I will outline how I planned to approach this problem.
Goal
Verify if only those nodes are changed which are a part of rootOperations.
Approach
As of now, I have pondered over InsertOperation and DeleteOperation. I will start with explaining my approach for InsertOperation.

Create inserted_paths metadata file in each directory of pure insert tests. This file contains the path of each inserted node (comes from the new model) in a separate new line. The test suite will further store this file as a list of strings (List<String>).
Now, the important part starts. I iterate over the patchedProgram (produced using Main.java#patchAndGenerateModel) and perform the following steps:

Ignore nodes which are implicit (they are automatically added so they do not need any verification) or are instances of CtPackage (unnamed package does not have a path). After that, I get the CtPath of the element which qualify this rule.
I check if any of the paths in inserted_paths (the metadata file) match the CtPath I got in the previous step.

If yes, I check for two assertions.

The path should return exactly one element when evaluated with new model.
The path should not be there in the prev model. However, if it is there, the .equals between the element from prev and new model should return false. Sometimes the path can resolve to some element so we should ensure that it is not equal to the element in new model.

If no, I again check for two assertions.

The path should exist in the prev model.
If it does not, the mapping of the element (SpoonMapping.get) should return the corresponding element in the prev model and path of that element should evaluate only once on prev model.

Step 2 ii a was enough but I have a strong reason to incorporate 2 ii b. If the latter step was not there, the tests would still pass irrespective of presence of inserted paths in the patched model.
For delete operations, I thought I would create another metadata file by the name of deleted_paths and check by iterating over the paths if each path is absent in the new model. However, this would require us to store the CtPath in a binary file. In other words, we would have to serialise it and store. Only then we will be able to call methods like lineFromDeletedPaths.evaluateOn(patchedModel). I am not even sure if this is feasible though.
Some drawbacks I noticed with this approach

Suppose an update operation, updates a literal and we record the new path of the updated node in inserted_paths metadata file. It is not possible to verify that the node has been updated just using the CtPath as the path would remain same.
Checking delete operations is quite tough. I can record the paths of the deleted nodes in a separate file but how can I check if those paths do not exist in the patched program. When I retrieve them from a metadata file, they are just Strings not instances of CtPath. That is why I thought we might need to serialise it which would make creation of test cases rather more complex.
The implementation as of now requires to think about a lot of cases and creation of test cases has also become a little tougher. I am kind of having second thoughts about this approach but I cannot think of something better also.

The inserted_paths metadata is a good start here. The test itself, though, well I'm not sure you've really thought through what you're trying to test. Recall that my feedback was that there's no check that a minimal patch is actually applied, rather one could just take the modified model and return that.
I don't see how the new test changes that, what you've got here is just a more complicated way to check that the structure of the model is equal to that of the new.java file. This is redundant; the original test checked structure just fine. That brings me to a related point, namely that you should not nuke your original test, as it does verify structure. Leave that as-is and add a new test.
And what should that new test do? It should not verify structure, that is done. In other words, you don't need to check that a given element exists in the patched model. What you need to check is that the expected elements come from the expected source file. Again, what I suggest that you do is to have a metadata file containing the CtPath to all elements that you expect to come from the new.java file. In the test, you can then iterate over all elements, and if an element has a path that matches the metadata, assert that it and all of its children are from new.java, otherwise assert that the element comes from prev.java.
Note that this makes pure delete patches trivial to verify: all elements should come from prev.java. Update patches to some extent may also fall under this category if you update things that aren't proper nodes, such as the name of a method (because changing the name of a method does not change its source position).

That brings me to a related point, namely that you should not nuke your original test

Yes, I plan to keep it. I have just deleted it for now.

if an element has a path that matches the metadata, assert that it and all of its children are from new.java, otherwise assert that the element comes from prev.java.

I think I am doing exactly that. I am not relying on checking the equality of the elements. Let me try to break this bit by bit.

you can then iterate over all elements

The while-block takes care of that.

if an element has a path that matches the metadata, assert that it and all of its children are from new.java

This if-condition takes care of that. Apart from checking that the node is there in new.java, I also check that the node is not there in prev.java. You have also mentioned that the children of nodes whose path is in metadata should also come from new.java. I have simply ignored them by checking if they start with any of the paths in metadata file.

otherwise assert that the element comes from prev.java.

The else-block takes care of that. Now, I am not able to implement this. Suppose this element which I am trying to insert was at index 1 in prev.java. But when I insert another statement at index 1, the element in question moves to index 2. So asserting its path that it comes from prev.java might fail because there is not statement at index 2 in prev.java.
prev.java
public void divide(int x, int y) {
    System.out.println(x/y);
}

new.java
public void divide(int x, int y) {
    if (y==0) {
        return;
    }
    System.out.println(x/y);
}

Now if (y==0) {return;}  can be asserted that it comes from new.java. But I am confused how to check if System.out.println comes from prev.java.

Path to System.out.println in prev.java: #method[signature=divide(int, int)]#body#statement[index=0]
Path to System.out.println in new.java: #method[signature=divide(int, int)]#body#statement[index=1]

Now when I assert path number 2 (that is what I will get when I iterate over new model), I will get an empty list because no statement exist at index 1 in prev.java.
I thought this would be possible to do if I use mapping but I am facing some problems there.

That brings me to a related point, namely that you should not nuke your original test

Yes, I plan to keep it. I have just deleted it for now.

if an element has a path that matches the metadata, assert that it and all of its children are from new.java, otherwise assert that the element comes from prev.java.

I think I am doing exactly that. I am not relying on checking the equality of the elements. Let me try to break this bit by bit.

you can then iterate over all elements

The while-block takes care of that.

if an element has a path that matches the metadata, assert that it and all of its children are from new.java

This if-condition takes care of that. Apart from checking that the node is there in new.java, I also check that the node is not there in prev.java. You have also mentioned that the children of nodes whose path is in metadata should also come from new.java. I have simply ignored them by checking if they start with any of the paths in metadata file.

No, it doesn't. It checks that the path fulfills two properties:

The path exists in the new model.

This is vacuously true unless the path is incorrect
It tells us nothing about which source file the element in the patched model came from

If the path doesn't exist in the old model, that evaluating the path on the old and new models yields different results

This is again vacuously true if the path is correctly specified, because if it is, then it must exist in the new model
Again, it tells us nothing about which source file the element in the patched model came from

When I say you need to check which source file an element originates from, I literally mean the source file, and not a model built from the source file.
// for any element whose path is listed in modified paths (and probably all children of that element)
assertThat(element.getPosition().getFile().getName(), startsWith(NEW_PREFIX));
// for all other elements
assertThat(element.getPosition().getFile().getName(), startsWith(PREV_PREFIX));

otherwise assert that the element comes from prev.java.

The else-block takes care of that. Now, I am not able to implement this. Suppose this element which I am trying to insert was at index 1 in prev.java. But when I insert another statement at index 1, the element in question moves to index 2. So asserting its path that it comes from prev.java might fail because there is not statement at index 2 in prev.java.

Same problem as the then-branch, it doesn't check anything about the origins of the elements. And also, you don't need to check if the element exists in the prev or new model, the only thing you need to verify is that each element in the patched model comes from the expected file.

To illustrate that your current approach doesn't work, I was going to implement patchAndGenerateModel as oldPackage.replace(newPackage), but then I realized that I passed just as many of the current tests with this implementation:
    static Pair<Diff, CtModel> patchAndGenerateModel(File prevFile, File newFile)
            throws FileNotFoundException {
        Pair<Diff, CtModel> diffAndModel = SpoonUtil.computeDiff(prevFile, newFile);
        return diffAndModel;
    }

I.e., do nothing at all, and it still passes the tests!

When I say you need to check which source file an element originates from, I literally mean the source file, and not a model built from the source file.

I did not pay attention to file. 🤦 Kept reading it as "model".

I did not pay attention to file. facepalm Kept reading it as "model". Let me give this another try.

A simple miscommunication, I could have been more clear. But do keep in mind, if you don't feel 100% clear on what I (or anyone, really) mean, ask for clarification: it's better to ask one question too many than the other way around :)
Go ahead and try again!

A simple miscommunication

No no. I am taking the blame on this. You were very clear now that I read your previous comments.

On it. It is going great till now but I faced two problems whose solution/workaround is yet to be found.

Operations like insertion of ThrownTypes cannot be checked for as we replace the entire signature so all the signatures come from the new.java which should not be the case.
Some elements throw NPE when I call element.getPosition().getFile(). For example, String in String[] args.

I also had one question. Why children of implicit elements are not implicit?

Fetching paths of some elements are throwing CtPathException. I am debugging it.

This is not a problem, you just need to alter the expectation: expect all of the thrown types in that collection to stem from the new revision.

Right! We can do this for all set-based collection elements.

The inserted_paths metadata file should IMO just be called something like new_revision_paths

I named it as such because I started with InsertOperations where it made sense but the approach extended well to others too. The suggested name sound better. I shall change it in the next commit.

Call element.getPosition().isValidPosition() to check if an element has a valid source position set.

So now we have three cases.

Element is from prev.
Element is from new.
Element is from an unknown file.

I understand why this is happening but I just hope this does not pose much problems. For example, by observation we would be able to say that the element comes from prev.java or new.java but our test just skips it anyway.

Note here that the canonical way of iterating over a Spoon AST is not to use the descendant iterator, but to use a visitor, which is something you may want to consider.

Okay. With CtScanner I can control what I want to do with an element in a much cleaner way. Is that the reason why CtScanner is recommended?

Because knowing the component type is useful for code transformation.

Okay, makes sense. Had eclipse compiler not terminated on ArrayTypeReference, the position of String would be valid. So I was just curious of the different behaviour across the builder and the visitor.

It's rarely, if ever, productive to assign blame; the concept has a very negative connotation. Search for "blame culture" and you'll see what I mean.

Taking responsibility for something is fine, but in any two-way communication responsibility is always shared.
Very nice perspectives :)
You should tell this to git and they might remove their git blame command. 😂 I am just joking. I get your point :)

@slarse Getting CtPath exceptions at unexpected places. I am looking into it.

This is getting hard to debug. For update/multiple_updates, the test throws CtPathException when it tries to fetch path of String here.
When I fetch parent of the element in question, I get String x which is confounding me. 😕

@algomaster99 Look at the update operations. They both include updating int x = 2 to String y = "Update", and updating int to String. Performing the update of int to String changes the parent of String to the parent of int.
I'd consider this a bug in gumtree-spoon.

See https://github.com/SpoonLabs/gumtree-spoon-ast-diff/issues/156
For now, I suggest we work around it by filtering update operations further (it appears only to be a problem for update operations).

Performing the update of int to String

Yes, I agree this is a child operation of updating int x = 2 to String y = "Update". So after the local variable is updated, the operation int -> String should not affect our model as int is no longer in the model as it has been detached from its parent, and that same position is taken by String. This thinking stems from your explanation here which said that the replacement happens on the model and not on the element itself.
Thus, if the application of UpdateOperation does not take place, the parent of string should have been String y = "updated" only. Or I think I might be missing something crucial in your explanation there.

See SpoonLabs/gumtree-spoon-ast-diff#156

This issue outlines that the root operations in case of UpdateOperation are incorrectly calculated. I agree with that. But I am also arguing that once the UpdateOperation is applied on the highest node in the model, the child operation should not matter.

For now, I suggest we work around it by filtering update operations further (it appears only to be a problem for update operations).

Okay. Should I just skip those tests using assumeFalse?

Thus, if the application of UpdateOperation does not take place, the parent of string should have been String y = "updated" only. Or I think I might be missing something crucial in your explanation there.

Replacing an element A with an element B is roughly equivalent to 1) removing A as a child of A.parent, 2) inserting B as a child of A.parent and 3) setting B.parent = A.parent. In this case, A = int and B = String, and the crucial part is the final step which sets String.parent = int.parent (i.e. the old parent). This is what causes the path exception and the strangeness in the final model, the model is in fact not sound.

setting B.parent = A.parent

Yes, I was missing this step. But this was not intuitive. Why do we bother about the replacement element? We should only be concerned with model where replacements are happening. I am sure people would have though this through but I would like to know about it.

This issue outlines that the root operations in case of UpdateOperation are incorrectly calculated. I agree with that. But I am also arguing that once the UpdateOperation is applied on the highest node in the model, the child operation should not matter.

See https://github.com/SpoonLabs/gumtree-spoon-ast-diff/issues/125. There is some awkwardness in going from GumTree to Spoon. The gist of it is that from a theoretical standpoint, an update operation cannot be a root operation as it is concerned with changing the content of a node, and not its content. It doesn't really make sense to say that changing a method's name is a root operation to adding a statement in its body, they are orthogonal concepts.

Okay. Should I just skip those tests using assumeFalse?

No, the model is invalid. The test failing is a good thing.
For now, since you do oldNode.replace(newNode), what you need to do is to filter out any update operations that occur on direct descendants of a node you intend to replace. In the future, we'll want to make this more granular: replacing an entire method because its name was updated is very rough.

I can show you a potential solution during the meeting tomorrow if you run into trouble.

Sure. I plan to work on it tonight. I let you know tomorrow. :)

Yes, I was missing this step. But this was not intuitive. Why do we bother about the replacement element? We should only be concerned with model where replacements are happening. I am sure people would have though this through but I would like to know about it.

The replacement element is of course part of the model. We must bother with it. In replacing an element, we must both link the parent to the new element, and the new element to the parent, otherwise the model is not consistent.
The replaced element is what we don't bother with, as that is no longer part of the model.

Oh, okay. Now I remember that you once told that child and parent have a two way link (direct children of A and parent of B) so it makes sense now!

Oh, okay. Now I remember that you once told that child and parent have a two way link (direct children of A and parent of B) so it makes sense now!

That's why you can do element.getParent() :)

@slarse I think I figured out a solution. I was initially trying to approach this problem using CtPaths. I was checking if any of the path of srcNode of UpdateOperation is a substring of some other node's path, I was excluding that operation overall.
Thankfully, the intellisense helped me discover the hasParent API which proved quite useful. :)

@slarse Incorporated the refactoring we talked about in the meeting. I also went over your comments. Will read the book you suggested. :)
Side note, GitHub should introduce a feature to "star" some comments. There are notes here and there which are very handy.

The function for filtering out non-root operations is not actually a part of this PR but it was necessary to pass the tests. I think it would be better if we can just write one line about it in the commit description which pops-up while squash-merging.

I found a problem with only comparing the elements. Consider the test case - literal+while+parameter.
We only need to focus on the UpdateOperation which updates assert i == 10 to assert i == 0. Or more specifically, the operation just updates the literal. So accordingly, we records its path in the metadata file.
#containedType[name=LiteralWhileParameter]#method[signature=main(java.lang.String[])]#body#statement[index=1]#condition#rightOperand

This is correctly evaluated on the patchedProgram. But a problem occurs when scanning over the patched model. When the scanner comes across the CtLiteral in this line, it checks if the node belongs to the list of insertedNodes (evaluates using insertedLines). And yes, it is able to find it because 0 from the int statement is being confused with 0 from the assert statement.
I think it would be better to keep the path comparison as well. I support comparing elements because they are more telling of the element's origination. Moreover, comparing elements will also help in checking for updates to access modifiers as checking paths won't be sufficient there (there should be no change in path of the element as they are virtual elements).

This is correctly evaluated on the patchedProgram. But a problem occurs when scanning over the patched model. When the scanner comes across the CtLiteral in this line, it checks if the node belongs to the list of insertedNodes (evaluates using insertedLines). And yes, it is able to find it because 0 from the int statement is being confused with 0 from the assert statement.

It sounds to me like you are using .equals (equality check) instead of == (reference equality check).
But in the spirit of just getting this merged already, just use the original path comparison. In combination with the structural check, it's sufficient.

It sounds to me like you are using .equals (equality check) instead of == (reference equality check).

I am using contains which implicitly uses equals.

But in the spirit of just getting this merged already, just use the original path comparison. In combination with the structural check, it's sufficient.

Yeah, this PR is getting really big anyway. I will just try to refactor the anonymous class then we can merge. I noticed that changing from path equality to element equality is structurally similar so the refactoring now won't be redundant.

I would avoid using anonymous classes for anything but very, very tiny things. Really, in Java 8 I'd only use lambdas.

I tried to focus on names and splitting methods as much as possible. The code is still quite big except one large chunk has been divided into multiple smaller ones.
I couldn't figure out using lambdas for refactoring. It kept throwing an error - Target type of a lambda conversion must be an interface (probably because CtScanner is an abstract class). So I just moved forwards with splitting the method first.

I would avoid using anonymous classes for anything but very, very tiny things. Really, in Java 8 I'd only use lambdas.

I tried to focus on names and splitting methods as much as possible. The code is still quite big except one large chunk has been divided into multiple smaller ones.
I couldn't figure out using lambdas for refactoring. It kept throwing an error - Target type of a lambda conversion must be an interface (probably because CtScanner is an abstract class). So I just moved forwards with splitting the method first.

Yes, CtScanner cannot be instantiated with a lambda. Only functional interfaces can be targets of lambdas.
When I mentioned lambdas, I didn't mean you should use one here. I meant that lambdas are a way to create anonymous classes, and that's IMO the only valid way to do so. Anonymous classes are otherwise just noise, because they require almost as much code as a named class and clutter up the place where they are used.

I meant that lambdas are a way to create anonymous classes, and that's IMO the only valid way to do so

I saw examples for creating comparator classes on StackOverflow. I will keep this in mind
Let me know if the code is readable to you. My opinion would be biased. I agree the code seems pretty long but that is because two test scenarios are inside one file only. I shall refactor it later.

@algomaster99 To be clear, this code is fine. I'm picking at the details. If you want to merge, go ahead, but there are IMO still improvements to be made.

I'm gonna merge now so we can move on :)

@slarse done with making it more readable. I think it was a good exercise as I at least put thought into naming variables and methods. If you think there can be improvements as well, do let me know.
I have kept few things for separate PRs.

Use element instead of path for comparison.
Split AppTest in to structural and source check.

I'm gonna merge now so we can move on :)

Go ahead.

@slarse done with making it more readable. I think it was a good exercise as I at least put thought into naming variables and methods. If you think there can be improvements as well, do let me know.

I would have put the scanner at the bottom of the file as it is called from the test method (I like to read code "top down").

Use element instead of path for comparison.
Split AppTest in to structural and source check.

Sounds good!

Well, we can, but it weakens the test as the path doesn't refer to a specific index (and we very much care about specific indices).

Yeah, you're right about that. I think this should be reported to spoon.

@slarse should we report this to Spoon? I don't think it would be a breaking change as I am sure paths are currently also identifying elements uniquely. This change would modify the getPath API to always use index=number.

Well, we can, but it weakens the test as the path doesn't refer to a specific index (and we very much care about specific indices).

Yeah, you're right about that. I think this should be reported to spoon.

@slarse should we report this to Spoon? I don't think it would be a breaking change as I am sure paths are currently also identifying elements uniquely. This change would modify the getPath API to always use index=number.

I think so. I think it's very confusing that you can specify the same path in two different ways.

I'm guessing that the reason for why names are used instead of indices sometimes is to make the path more resilient to shifted statements. It may be a reason to keep it as-is, the use case here is kind of unique.

If it is able to resolve statements using index also, then I do not see a point. We would need to look for a test case which fails when using index but works well if we use name.

For this use case, yes. But using the name still makes the path more resilient to shifting statements, i.e. it's likely that you can still find the element the path was built from even when an index shifts. This is the entire problem for this use case, but may be beneficial in other use cases where you just want to be able to find the same element across different variations of the same model.

just want to be able to find the same element across different variations of the same model.

Cool. In that case, I will just modify paths in our metadata.

Perhaps a new method would be appropriate, e.g. getPrecisePath() which should to the extent possible should create a path that always uses indices instead of names.

Let's open an issue there. I think more insights will be better.
We could propose both:

Modify getPath.
Introduce getPrecisePath.

I just hope someone comes up with a test case which would oppose 1.


Add support for Angular (not AngularJS)

I'm going to use page-object to test Angular apps.
As far as i can see, there is support for AngularJS (ajax calls count), but not for Angular (2+).
https://github.com/cheezy/page-object/tree/master/lib/page-object/javascript
Is there a plan to support angular?

create PR ;) it's should not be hard if Angular have ajax count buildin

There is a watir_angular gem that is still in beta that needs to have requirements honed. For instance I don't like the way it is currently initialized. But It should already be compatible with page object gem. If it isn't let's get it fixed so it is. Would love help on it since I don't actually use angular. :-)

@entwanderer do you know the JavaScript that will return the number of current ajax requests?  In AngularJS it is 'angular.element(document.body).injector().get('$http').pendingRequests.length;'. If you can find the equivalent code for Angular then I can easily add it.

window.getAllAngularTestabilities().filter(zone=>!zone.isStable()).length;
isStable() checks if pendingCount is 0 and the given zone has no pendingMacroTasks and does not return the number of requests pending
Getting the actual number of pending requests has been deprecated.


Add an additional newline after progress bar

This fixes a small output glitch of parallel testing.

@swift-ci please smoke test


[base-cluster] cilium should be included

Otherwise we can't automatically turn on it's monitoring integration

can it?

After thinking about this it's not really possible, as flux needs a CNI and cilium requires none
I guess this is either on for managed clusters and off for hands-off clusters? @marvinWolff

Closed by the t8s-cluster chart


Modify pyobject_native_type to take path instead of ident

So that we can use this macro outside this crate.
Almost same as #158.

Some notes:

we can't use a macro outside the crate, if we use $crate::std in it
we have to make python module public to export pyobject_native_type

Thank you!


webview_flutter plugin doesn't work when setState is called in onPageFinished function

It just shows a blank page when calling setState in onPageFinished function. If I remove setState call, then it works fine.
my code below:
 void _pageLoadingDone(String value) {
    setState(() {
      _stackToView = 0;
    });
    print(value);
  }

 Widget build(BuildContext context) {
    return WebView(
      key: UniqueKey(),
      javascriptMode: JavascriptMode.unrestricted,
      initialUrl: 'https://google.com',
      onPageFinished: _pageLoadingDone,
    );
}

Hi @liyuqian
Are you still experiencing the issue with the latest stable version of Flutter?
If so, can you please provide your flutter doctor -v
and a reproducible minimal code sample?
Thank you

The issue is already long time not active and without answer.
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, logs and the output of flutter doctor -v please.


uninitialized constant Octopress::Tags::Quote (NameError)

$ jekyll build --trace
/Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/octopress-pullquote-tag-1.0.0/lib/octopress-pullquote-tag.rb:47:in `<top (required)>': uninitialized constant Octopress::Tags::Quote (NameError)
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/bundler-1.7.13/lib/bundler/runtime.rb:76:in `require'
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/bundler-1.7.13/lib/bundler/runtime.rb:76:in `block (2 levels) in require'
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/bundler-1.7.13/lib/bundler/runtime.rb:72:in `each'
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/bundler-1.7.13/lib/bundler/runtime.rb:72:in `block in require'
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/bundler-1.7.13/lib/bundler/runtime.rb:61:in `each'
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/bundler-1.7.13/lib/bundler/runtime.rb:61:in `require'
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/bundler-1.7.13/lib/bundler.rb:134:in `require'
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/jekyll-2.5.3/lib/jekyll/plugin_manager.rb:38:in `require_from_bundler'
    from /Users/tohuw/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/jekyll-2.5.3/bin/jekyll:16:in `<top (required)>'
    from /Users/tohuw/.rbenv/versions/2.2.0/bin/jekyll:23:in `load'
    from /Users/tohuw/.rbenv/versions/2.2.0/bin/jekyll:23:in `<main>'

Gemfile
Invocation (on about.md):
{% pullquote %}
When writing long-form posts, I find it helpful to include pull-quotes, which help
those scanning a post discern whether or not a post is helpful. It is important to
note, {" pull-quotes are merely visual in presentation and should not appear twice in the text. "} That
is why it is preferred to use a CSS only technique for styling pull-quotes.
{% endpullquote %}

Thanks for the report. This should be fixed in the latest version 1.0.1.


How to close react-context menu on document scroll?

Thanks for the awesome context menu.
I have opened the context menu on elements which are inside a scroll able div.
Now i want to close the context Menu when I scroll the div.
Please help

You can add a scroll listener on the element and call hideMenu from react-contextmenu/lib/actions

Ok lemme try

Thanks alot it worked


Settings Menu

What would you like to be added?
A menu for creating various default user settings.
One such setting could be to reverse ctrl+click behavior for opening links or editing YAML data, as mentioned in #78. Other users may have additional settings, feel free to populate below.
Why is this needed?
Customizable settings allow for better integration into existing user workflows and UX

I've managed to do without a Settings tab so far, but I think this is a good example of a preference that should work globally 👍

I would also love to see the option to expose metadata such as due date, assignee, and #tags from a card on the board view.  Not everyone needs those on that page, but to replace my current kanban board, I'd love to see a little more flexibility on what displays on the card faces.

I would like a setting to define how dates should be formatted and displayed in the table view, eg, YYYY-MM-DD or MM/DD/YYYY or DD.MM.YYYY

I'm closing this issue as I've added a settings menu in 1.5.0 for configuring how to quote strings in front matter.
While there are more ideas on what to customize, let's create more specific issues for the things you'd like to customize so that we can track them individually.


A plugin must either be a function or an object with an "install" function in Vue 3

This is:

Bug
Feature request
Question
Idea

Specifications

AOS version:
OS:
Browser:

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Detailed Description

Possible Solution

Even though its been a while, but its for future developers
If you're getting this warning with vite and vue 3, then just remove
app.use(AOS)

Thats it !
I'm gonna put a sample code for vue 3.
import { createApp } from 'vue'

// importing plugins
import { createMemoryHistory, createRouter } from 'vue-router'

import AOS from 'aos'
import 'aos/dist/aos.css'

import Index from './pages/website/Index.vue'

const router = createRouter({
    history: createMemoryHistory(),
    routes: [
        {
            path: '/',
            name: 'home',
            component: Index
        }
    ],
});

router.beforeEach((to, from, next) => {
    AOS.init(); // Initialize AOS
    next();
});

app
.use(router)
.mount('#app');

Hope this will help someone.

Even though its been a while, but its for future developers
If your environment is vite with vue 3, and the warning is indicating to AOS plugin, then just remove the following line from your js file.
app.use(AOS)

Thats it !
I'm gonna put a sample code for vue 3.
import { createApp } from 'vue'

// importing plugins
import { createMemoryHistory, createRouter } from 'vue-router'

import AOS from 'aos'
import 'aos/dist/aos.css'

import Index from './pages/website/Index.vue'

const router = createRouter({
    history: createMemoryHistory(),
    routes: [
        {
            path: '/',
            name: 'home',
            component: Index
        }
    ],
});

router.beforeEach((to, from, next) => {
    AOS.init(); // Initialize AOS
    next();
});

app
.use(router)
.mount('#app');

Hope this will help someone.


sequence number in secured message format

Hello,
I'm implementing Responder SPDM 1.1.2 secure session, planning to support only application data which is in-0session SPDM message like GET_MEASUREMENT, HEARTNEAT and END_SESSION
From the spec DSP277, sequence number field is marked as "NO" in the recommendation column of Secured Message fields definition. Does that mean I can completely avoid this field (as I don't see any usage) or better to allocate 2 bytes and assign value "ZERO"...
session_id = 4 bytes
sequence_num = 0 bytes (or should I allocate 2 bytes and assign"ZERO")
length = 2 bytes
From the code: spdm_secured_message.h
/* The length of sequence_number between HEADER_1 and HEADER_2 is transport specific.*/
I see in the code you have allocated UINT64_t and assigned zero, never used anywhere to increment the value..

What transport are you using underneath 277? That will tell you what the size of the partial sequence number is. For example MCTP says that it's two bytes.

MCTP = transport

Can you point me to where in the code/doc it says 2 bytes for MCTP transport
2)In the above case, where application data is in-session SPDM messages like GET_MEASUREMENT, HEARTBEAT and END_SESSION - How does the sequence number fit in this case?

https://www.dmtf.org/sites/default/files/standards/documents/DSP0276_1.1.0.pdf says

The Partial Sequence Number field is the Sequence Number field described in DSP0277. The Partial Sequence
Number field shall be two bytes in length and shall contain the lower 16 bits of the Sequence Number. The field
presence requirement for Partial Sequence Number shall always be present for Encryption and Message
Authentication or Message Authentication Only sessions.

In the above case, where application data is in-session SPDM messages like GET_MEASUREMENT, HEARTBEAT and END_SESSION - How does the sequence number fit in this case?

Sequence number is used to construct the IV used by the AEAD algorithm. Note that 274 shows how to derive an "IV" but that's really an IV mask or salt.

Sequence number is used to construct the IV used by the AEAD algorithm. Note that 274 shows how to derive an "IV" but that's really an IV mask or salt.
I'm still trying to digest this :)
I have the IV calculated per 274, and will be using AES 256-bit GCM as AEAD cipher, could not see anywhere mentioning about "Sequence number is used to construct the IV used by the AEAD algorithm"
I'm missing anyhting? or it there any other doc that I need to refer to other than 274, 277, 276...

From 277:

Thanks

I got the answer for this, will close the issue


Dilbert.com broken by site redesign

Dilbert.com's launched a new site design, no previous button on the main page, just infinite scroll.  Date pages work and are the same as before, and have previous/next buttons on the sides.  You have to click on a strip to get to one of those however.
Dosage fails both on current day and specific dates, error is the same for both:
dosage Dilbert:2015-01-13
Dilbert> ERROR: Patterns ['<\\s*[aA]\\s+(?:[^>]*\\s+)?[hH][rR][eE][fF]\\s*=\\s*"(/\\d+-\\d+-\\d+/)"[^>]*STR_Prev[^>]*>'] not found at URL http://dilbert.com/.

Strip zoom is also gone, but the strips are larger than before, just slightly smaller than the original zoom sizes.
I'm not good at building new definitions, so I have no clue where to start to fix this.  I figure it's popular enough lots of people will be wanting it fixed, so reporting it so the devs will know about it. :)

This has been fixed with the last merge.


Documentation: add C++ Tracker to Wiki page

It is currently missing from: https://github.com/snowplow/snowplow/wiki/Trackers
Tracker page: https://github.com/snowplow/snowplow-cpp-tracker

Done


Add LLC CERERIS to orgs-using-d.dd

Our company is fully transferred to the development through language D. We dream to make D one of the most popular programming languages in our country. Hopefully all the changes right.
CEO LLC CERERIS
Kozhevnikov Peter

Looks good to me. Though, I see one small potential improvement, to remove some stutter - what do you think of removing the company name from the logo, since it'll appear below the image anyway, and use just the green sphere like on your website?

Thank you for a great idea. Fixed

Great, all that's left now is to squash the commits and this is ready to merge.

All fixed.

Something must've went wrong with the squash, as there are 9 commits where there should be 1.

Thank you so much. Understood.


watch : Exited with error code 139 watch : Waiting for a file to change before restarting dotnet...

Problem encountered on https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/run
Operating System: linux
Provide details about the problem you're experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant.

139 usually means access violation. Is this error consistent? Do you get this running other dotnet commands?

Yes! This is a little bit worrying. This happens when I want to run a small project in .NET 6 or .NET 5. This message is:
watch : Started

watch : Exited with error code 139
watch : Waiting for a file to change before restarting dotnet...

And that appears when I use the command dotnet watch run or dotnet run.  Also when I try to run from the folder bin/Debug/My-proyecto, another message appears: Violación de segmento ('core' generado), which translates to English (if I am not mistaken) as Core Dump (Segmentation fault). I don't know why this happens, but what is clear is I cannot use .NET in my machine.
Some info:

Operating system: Ubuntu 20.04 with kernel 5.13.0-28-generic.
This happens with dotnet version 6.0.101 and the last from .NET 5 (I think it is 5.0.404).

Same problem with dotnet version 6.0.102.

Is it possible you're building from/to a protected directory?

The solution is weird, I don't know why. I have installed dotnet through snap and it was working fine, no problem there. Suddenly on February when I tried to run some projects, it didn't work, it showed watch : Exited with error code 139. I tried two possible solutions: the first one, I downloaded the binaries from here and I used the executable (for the versions 5 and 6). Same error. The second solution was to install from apt (I am using Ubuntu) using this guide. It worked!. Again, I don't know why, but I can run any project using dotnet run or dotnet watch run. Although this does not answer the question: why did that kind of error appear?

We were debugging an issue where our .NET containers (linux) sometimes exit with 139 errors and I later found that if the .NET app (which runs as the entrypoint to the container) throws an unhandled exception (same as in @rosgori's comment), then the container consistently has an exit code of 139.
What is even more confusing is that if you shell into the same container and run the "dotnet my-app.dll" manually you get an exit code of 134 (Abort) when an unhandled exception is thrown. You can simulate this with any .NET app (from 3.1 to 6.0) where you simply throw an exception in the Main method.

https://github.com/dotnet/core/issues/7112#issuecomment-1033292899   thanks your solutions works

We are trying to fix our docs to warn people about snap being mostly broken for dotnet tools: https://github.com/dotnet/docs/pull/31045

The solution is weird, I don't know why. I have installed dotnet through snap and it was working fine, no problem there. Suddenly on February when I tried to run some projects, it didn't work, it showed watch : Exited with error code 139. I tried two possible solutions: the first one, I downloaded the binaries from here and I used the executable (for the versions 5 and 6). Same error. The second solution was to install from apt (I am using Ubuntu) using this guide. It worked!. Again, I don't know why, but I can run any project using dotnet run or dotnet watch run. Although this does not answer the question: why did that kind of error show up?

Thank you so much! The 2nd solution did helped me.

I'm getting the same issue on archlinux, I'm using dotnet 6.0 I had no clue why this happen
dotnet watch ❌ Exited with error code 139
dotnet watch ⏳ Waiting for a file to change before restarting dotnet...```

@nandafirmans I don't do much on Linux, but it doesn't look like archlinux is currently on the supported distro list for .NET 8: https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md.
@richlander Do you know if there are known issues running .NET on archlinux?

Does anyone have updates regarding this issue? We are currently using .NET Core SDK 7 (mcr.microsoft.com/dotnet/sdk:7.0) on Amazon Elastic Container Service (ECS). For several weeks now, we have been encountering these errors where the container is abruptly terminated with exit code 139. Unfortunately, there is no additional information provided to help us comprehend the root cause of the error.

Facing the same issue as @diegodfsd above. Tried Ubuntu amd64 and Alpine amd64 image. Same issue. Nothing in logs. Seems more easily triggered on Ubuntu vs Alpine, which takes longer. Tried debugging it for weeks now.

@arhue / @diegodfsd Do you have fix to this issue yet? It's being a bottle neck for one of my service with similar setup on ECS

Hi @huzaynbolt we solved our problem. In our case, the cause behind the abruptly terminated ECS Tasks was the usage of the IronPdf library that uses chromium, but after we made the library upgrade the issue was fixed.

How do your debug on ECS then? That's my struggle at the moment. Since ECS terminated the task upon the error and I can't retrieve the logs after it stopped

@huzaynbolt Sorry about the delay, missed the notification. Yes, for us it was because application was running out of memory


[BUG] As root admin cannot see instances in Kubernetes cluster created as user

Describe the bug
Root admin is not displayed with instances of a kub cluster created by user
To Reproduce
Steps to reproduce the behavior:

Create a cluster as user
Login as root and list the instances of the cluster

Expected behavior
Instances listed
Screenshots
As root admin

As User

Desktop (please complete the following information):

OS: Mac
Browser chrome
Version 80
Tested in a trillian env

@borisstoyanov please test and close. PR merged on master.

ping @vladimirpetrov  @borisstoyanov

I've confirmed this, closing.


Client's extra_headers is not propagated when getting a Project

I am adding extra headers to my label-studio Client in order to pass an extra reverse proxy we are running:
from label_studio_sdk import Client
ls = Client(url=LABEL_STUDIO_URL, api_key=API_TOKEN, extra_headers={"X-MY-CUSTOM-AUTH": "123456790"})

The following works fine:
res = ls.make_request("GET", "/api/projects")
# returns projects

Using the SDK fails:
res = ls.get_project(10)
# returns 'unauthenticated', because the header `X-MY-CUSTOM-AUTH` is not provided

It seems that the Project class is initialized without propagating the extra_headers, and thus subsequent calls fail.

Thank you very much for your contribution!

Just commenting that this problem is also present for client.start_project() where the instantiated project object is not passed extra_headers
https://github.com/HumanSignal/label-studio-sdk/blob/490d95cde0fb7517cc65457ba3c964580fd692b1/label_studio_sdk/client.py#L234-L239
assigning the headers to the requests.Session is a temp solution to avoid this issue


Vagrant commands are not working with iTerm

FYI this last problem in screenshot above does not occur when I ssh with iTerm into the containers. That works just fine with iTerm settings as you see above. It is only when we try to SSH into the peer that things go wrong.

Fixed in Master.

Fixed in Prod.


CLICKHOUSE-3839 add partition_id in system.merges

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Consider adding partition_id also to part_log.


What test was running during a signal trap?

Right now we get the backtrace of all the threads when trapping a signal from a timeout for example, but it's still difficult to pin point which test the calls are coming from..
Is there a way to output the test or tests that were running at the time of the signal trap? We get the "retry the previous batch of tests" in the INFO logs, but not for the current batch of tests..

The spec file could be in the main thread backtrace as shown here:
https://docs.knapsackpro.com/ruby/troubleshooting/#why-does-the-ci-node-hang-backtrace-debugging
If not, then something else could freeze, like factories (FactoryBot) etc.
You may also see the name of the test case in the output right before the thread backtraces if you use rspec --format documentation. It's easier to catch the problematic test case then.
Feel free to share the full txt output from a node that hangs to the support email https://knapsackpro.com/contact
We can analyze it. Perhaps there is a better way to narrow down the root issue or automate it somehow so the output is more readable.

It may be helpful to include the seed in the debug logs BEFORE a batch of tests are executed, in the case of a signal trap due to timeout, we never get to see the seed and it makes it difficult to try to reproduce the issue locally.


Scope of ASDF beyond Astronomy?

At the moment, the tagline for the repo is ASDF (Advanced Scientific Data Format) is a next generation interchange format for astronomical data - I wonder if it would be worth making it sound like it would also be useful to other fields, e.g. being developed for astronomical and other scientific data?

Note that it looks like the name is also being used for a new seismic data format:
http://asdf.readthedocs.org/en/latest/
https://pypi.python.org/pypi/pyasdf
:-/

Maybe for PyPI you should reserve https://pypi.python.org/pypi/asdf since it's still available?

Oh, dammit.  When did that happen?  Maybe we need to rename again...

If these seismology guys are serious about claiming the name ASDF for their data format we may need to rename; the potential for confusion is too great.  Unless we had prior art on it.  I'm not sure.

That tagline is updated, and I've reserved asdf on PyPI (at least for now).  Bummer on this -- I could have sworn I did a PyPI search for "pyasdf" when we chose the name, and I should have squatted on the name then.  It's not the end of the world to rename this project/package to asdf from pyasdf, but that still doesn't resolve the potential confusion with the seismic folks.

And of course, we have "pyasdf" on readthedocs and "asdf" on PyPI, and they have the inverse.  That's kind of a mess.  Maybe we could propose a friendly swap? ;(

Why didn't they call it amsdf?

Yeah, even if we end up both using the name ASDF it looks like we'll have to talk.

Why not rename to USDF, the Ultimate Scientific Data Format? :wink:

Or UIOP.  No ideas for what it stands for.  Maybe nothing.  Maybe everything.

*cough* @krischer

It looks like this issue has been addressed.


Error code missing in Swagger

The error {"code":9,"message":"failed to delete pipeline: pipeline has connectors attached"} isn’t documented in Swagger
/v1/pipelines/{id}
Request Method: DELETE
400
message: "failed to delete pipeline: pipeline has connectors attached"

dupe


[2,5pt] Create MusicAlbum class - Team Member #2

Create MusicAlbum class in a separate .rb file.
All MusicAlbum class properties visible in the diagram should be defined and set up in the constructor method.

Pull request for this task


Add Job Name Validation Check

Azkaban requires all job names to be unique within a project. The current behavior when there's a naming collision is for Azkaban to throw a 500 error that doesn't provide useful details to the deploying user about what went wrong. This leads to a lot of confusion for developers who are encountering the issue for the first time.
Instead of the current behavior, I propose a pre-deploy check for uniqueness among job names in a project. This provides the benefit of being able to provide a more detailed error message that will allow developers to resolve their naming collision more quickly.

Apologies for the delayed response. There's already a duplicate job name check; can you elaborate on when it's not sufficient?


AC enable don't work with MAX 2

Hey,
I found a new bug.
For me the AC output cannot be switched on the Delta 2 MAX and River 2 MAX. If you set the variable "inv.cfgAcEnabled" to "true" it will be set back to "false" after a few seconds.
Strangely enough, it works without any problems with the River 2 PRO.

This is strange, because the newer devices should have same structure and content. We have to investigate the telegrams.
Please do the following:

enable/activate the debug checkboxes for msgCmd, msgSet/Get
set the adapter into debug mode, usually this restarts the adapter
do the command action from the app
do the opposite command from the app
Do the command action from iob
Do the opposite command action from iob
Go to the log and paste here everything what is after adapter start until that point

The last 5 steps should be repeated for the other device.
You can erase the last digits of your device serial number.

River 2 MAX:
Enable AC with APP:

ecoflow-mqtt.0 | 2024-05-27 12:57:09.402 | info | state ecoflow-mqtt.0.R611ZEB5XECQ0437.inv.cfgAcEnabled changed: true (ack = true)
-- | -- | -- | --
ecoflow-mqtt.0 | 2024-05-27 12:57:07.058 | info | state ecoflow-mqtt.0.R611ZEB5XECQ0437.mppt.cfgAcEnabled changed: true (ack = true)

Disable AC APP:

ecoflow-mqtt.0 | 2024-05-27 13:00:34.731 | info | state ecoflow-mqtt.0.R611ZEB5XECQ0437.mppt.cfgAcEnabled changed: false (ack = true)
-- | -- | -- | --
ecoflow-mqtt.0 | 2024-05-27 13:00:33.699 | info | state ecoflow-mqtt.0.R611ZEB5XECQ0437.inv.cfgAcEnabled changed: false (ack = true)

cfgAcEnabled "true" with ioBroker (no change on River 2 MAX):

ecoflow-mqtt.0 | 2024-05-27 13:01:29.399 | info | state ecoflow-mqtt.0.R611ZEB5XECQ0437.inv.cfgAcEnabled changed: true (ack = false)
-- | -- | -- | --

cfgAcEnabled "false" with ioBroker (no change on River2 MAX):

ecoflow-mqtt.0 | 2024-05-27 13:02:34.861 | info | state ecoflow-mqtt.0.R611ZEB5XECQ0437.inv.cfgAcEnabled changed: false (ack = false)
-- | -- | -- | --

thanks for the test, but unfortunately it must be repeated after the adapter is in debug mode. You can achieve this by going into adapter setting and in the header change from info to debug via the "pencil" right beside the "info" text.

you can also post the log which includes the timeframe of the test. I can dig into it, to see the interactions.

iobroker.2024-07-02.log
Log.txt
Does this help? Test (AC disabled) on 12:10:08 on the R351ZEB4HF460435 Ecoflow

The log.txt does contain the command which was initiated by iobroker, which looks as expected.
The ACenable command from the APP is missing in the log, that would be needed to compare the syntax.
So a new log.txt would be nice, where the command from the App is captured.
BTW there are many other issues part of that log, from other adapters and scripts.
Some of the other issues are related to the ecoflow adapter, because the telegrams contain unknown datapoints.
Therefore it would be good to tick additionally the msgUpdate, then the log contains the received telegram.

Hi, here the same with the River2 Max

Off with App
On with App
Off IOB

ecoflow-mqtt.0
2024-07-27 14:34:12.349	debug	R611ZEB5XF1D1931 ->set w/o params{"id":652020900,"version":"1.0","operateType":"getAllTaskCfg","moduleType":1,"time":4563872,"code":"0","data":{"general":{"taskSavedNum":0,"conflictItem":[128],"taskMaxNum":6,"productType":71},"timeTask":{"taskCfgs":[{"taskIndex":0,"week":4,"timeScale":[0,0,0,0,0,0,0,0,0,255,255,255,63,0,0,0,0,0],"year":2024,"isCfg":0,"type":0,"isEnable":0,"sec":0,"taskPrior":0,"min":0,"timeParam":1036419,"month":4,"hour":0,"timeMode":0,"day":3},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255}],"totalTaskNum":0}}}
ecoflow-mqtt.0
2024-07-27 14:34:12.039	debug	R611ZEB5XF1D1931 river2max -> set undefined {"params":{},"from":"iOS","lang":"de-de","id":"652020900","moduleSn":"R611ZEB5XF1D1931","moduleType":1,"operateType":"getAllTaskCfg","version":"1.0"}
ecoflow-mqtt.0
2024-07-27 14:34:01.189	debug	[store station] R611ZEB5XF1D1931 not processed inv state: FastChgWatts value 0
ecoflow-mqtt.0
2024-07-27 14:34:01.186	debug	[store station] R611ZEB5XF1D1931 not processed inv state: SlowChgWatts value 0
ecoflow-mqtt.0
2024-07-27 14:33:58.266	debug	[store station] R611ZEB5XF1D1931 not processed inv state: FastChgWatts value 0
ecoflow-mqtt.0
2024-07-27 14:33:58.263	debug	[store station] R611ZEB5XF1D1931 not processed inv state: SlowChgWatts value 0
ecoflow-mqtt.0
2024-07-27 14:33:58.257	info	state ecoflow-mqtt.0.R611ZEB5XF1D1931.inv.cfgAcEnabled changed: true (ack = true)
ecoflow-mqtt.0
2024-07-27 14:33:52.332	debug	R611ZEB5XF1D1931 ->set w/o params{"id":632020836,"version":"1.0","operateType":"getAllTaskCfg","moduleType":1,"time":4543902,"code":"0","data":{"general":{"taskSavedNum":0,"conflictItem":[128],"taskMaxNum":6,"productType":71},"timeTask":{"taskCfgs":[{"taskIndex":0,"week":4,"timeScale":[0,0,0,0,0,0,0,0,0,255,255,255,63,0,0,0,0,0],"year":2024,"isCfg":0,"type":0,"isEnable":0,"sec":0,"taskPrior":0,"min":0,"timeParam":1036419,"month":4,"hour":0,"timeMode":0,"day":3},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255}],"totalTaskNum":0}}}
ecoflow-mqtt.0
2024-07-27 14:33:52.041	debug	R611ZEB5XF1D1931 river2max -> set undefined {"params":{},"from":"iOS","lang":"de-de","id":"632020836","moduleSn":"R611ZEB5XF1D1931","moduleType":1,"operateType":"getAllTaskCfg","version":"1.0"}
ecoflow-mqtt.0
2024-07-27 14:33:46.174	debug	R611ZEB5XF1D1931 river2max -> set undefined {"from":"Android","lang":"en-us","id":"664702794","moduleType":3,"operateType":"acOutCfg","version":"1.0","params":{"enabled":0},"moduleSn":"R611ZEB5XF1D1931"}
ecoflow-mqtt.0
2024-07-27 14:33:46.160	debug	/app/1772580463883280385/R611ZEB5XF1D1931/thing/property/set Message succesfully published.
ecoflow-mqtt.0
2024-07-27 14:33:46.160	debug	publish {"from":"Android","lang":"en-us","id":"664702794","moduleType":3,"operateType":"acOutCfg","version":"1.0","params":{"enabled":0},"moduleSn":"R611ZEB5XF1D1931"}
ecoflow-mqtt.0
2024-07-27 14:33:46.159	debug	publish /app/1772580463883280385/R611ZEB5XF1D1931/thing/property/set
ecoflow-mqtt.0
2024-07-27 14:33:46.159	debug	prep cmd R611ZEB5XF1D1931 river2max cfgAcEnabled false {"valName":"enabled","moduleType":3,"operateType":"acOutCfg","params":{"enabled":0}}
ecoflow-mqtt.0
2024-07-27 14:33:46.159	info	(ack=false) ->cmd : channel inv state cfgAcEnabled
ecoflow-mqtt.0
2024-07-27 14:33:46.158	info	state ecoflow-mqtt.0.R611ZEB5XF1D1931.inv.cfgAcEnabled changed: false (ack = false)
ecoflow-mqtt.0
2024-07-27 14:33:40.315	debug	[store station] R611ZEB5XF1D1931 not processed inv state: FastChgWatts value 0
ecoflow-mqtt.0
2024-07-27 14:33:40.311	debug	[store station] R611ZEB5XF1D1931 not processed inv state: SlowChgWatts value 0
ecoflow-mqtt.0
2024-07-27 14:33:40.307	info	state ecoflow-mqtt.0.R611ZEB5XF1D1931.inv.cfgAcEnabled changed: true (ack = true)
ecoflow-mqtt.0
2024-07-27 14:33:39.920	info	state ecoflow-mqtt.0.R611ZEB5XF1D1931.mppt.cfgAcEnabled changed: true (ack = true)
ecoflow-mqtt.0
2024-07-27 14:33:37.760	debug	R611ZEB5XF1D1931 ->set w/o params{"id":617399632,"version":"1.0","operateType":"acOutCfg","moduleType":5,"time":4529262,"code":"0","data":{"ack":0}}
ecoflow-mqtt.0
2024-07-27 14:33:37.416	debug	R611ZEB5XF1D1931 river2max -> set undefined {"params":{"enabled":1,"out_freq":255,"out_voltage":4294967295,"xboost":255},"from":"iOS","lang":"de-de","id":"617399632","moduleSn":"R611ZEB5XF1D1931","moduleType":5,"operateType":"acOutCfg","version":"1.0"}
ecoflow-mqtt.0
2024-07-27 14:33:34.382	debug	[store station] R611ZEB5XF1D1931 not processed inv state: FastChgWatts value 0
ecoflow-mqtt.0
2024-07-27 14:33:34.377	debug	[store station] R611ZEB5XF1D1931 not processed inv state: SlowChgWatts value 0
ecoflow-mqtt.0
2024-07-27 14:33:34.368	info	state ecoflow-mqtt.0.R611ZEB5XF1D1931.inv.cfgAcEnabled changed: false (ack = true)
ecoflow-mqtt.0
2024-07-27 14:33:33.965	info	state ecoflow-mqtt.0.R611ZEB5XF1D1931.mppt.cfgAcEnabled changed: false (ack = true)
ecoflow-mqtt.0
2024-07-27 14:33:32.541	debug	R611ZEB5XF1D1931 river2max -> set undefined {"params":{"enabled":0,"out_freq":255,"out_voltage":4294967295,"xboost":255},"from":"iOS","lang":"de-de","id":"612520575","moduleSn":"R611ZEB5XF1D1931","moduleType":5,"operateType":"acOutCfg","version":"1.0"}
ecoflow-mqtt.0
2024-07-27 14:33:32.311	debug	R611ZEB5XF1D1931 ->set w/o params{"id":612020850,"version":"1.0","operateType":"getAllTaskCfg","moduleType":1,"time":4523832,"code":"0","data":{"general":{"taskSavedNum":0,"conflictItem":[128],"taskMaxNum":6,"productType":71},"timeTask":{"taskCfgs":[{"taskIndex":0,"week":4,"timeScale":[0,0,0,0,0,0,0,0,0,255,255,255,63,0,0,0,0,0],"year":2024,"isCfg":0,"type":0,"isEnable":0,"sec":0,"taskPrior":0,"min":0,"timeParam":1036419,"month":4,"hour":0,"timeMode":0,"day":3},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255}],"totalTaskNum":0}}}
ecoflow-mqtt.0
2024-07-27 14:33:32.041	debug	R611ZEB5XF1D1931 river2max -> set undefined {"params":{},"from":"iOS","lang":"de-de","id":"612020850","moduleSn":"R611ZEB5XF1D1931","moduleType":1,"operateType":"getAllTaskCfg","version":"1.0"}

Now it is clear what needs to be changed. Thanks for the log.

it should be fixed now with version 0.0.35.
you can install it from git or npm.
please check and report.

Did you have a chance to check it?

Hi, sorry, i was on holiday the last 3 weeks. I trie to test it in the next days

Hi, it dont work, i can not switch the Ac Power Output (ecoflow-mqtt.0.xxxxxxxxxxxxx.inv.cfgAcEnabled) with the Adapter. When its false and i want tu turn it on with true, the datapoint shows true in red color and nothing happens on the Delta 2 Max, a few seconds later the Datapoint changes to false, the same when it on (true) and i want to turn it to off (false), the Datopoint shows red false and a Moment later it turns to true.
Sorry for my bad english. I hope you understand what i mean.

In total it looks a bit strange.
Maybe it has something to do with unexpected messages, which then skip the whole message.
I have created a version 1.0.3 which may help.
If it still shows that problem, then please set some additional "ticks" in the adapter config (see screenshots)

as an example the debug enable also at the device

Hi, it dont work
New Installation over GitHub today Version 1.0.3
i have set the additional "ticks" from your sreenshots
Here is a new Log
Off with App
On with App
Off (false) with IOB
2024-09-06 09:24:44.206 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372256939343986,"version":"1.0","timestamp":1725607484,"moduleType":"3","params":{"inv.dcInVol":0,"inv.cfgAcWorkMode":0,"inv.SlowChgWatts":0,"inv.dcInAmp":0,"inv.cfgAcOutFreq":2,"inv.outputWatts":0,"inv.errCode":0,"inv.dcInTemp":0,"inv.invOutFreq":0,"inv.chargerType":0,"inv.reserved":[0,0,0,0,0,0,0,0],"inv.acInAmp":0,"inv.fanState":0,"inv.cfgAcXboost":0,"inv.cfgAcEnabled":0,"inv.outTemp":22,"inv.invType":0,"inv.cfgAcOutVol":0,"inv.acDipSwitch":0,"inv.acInVol":0,"inv.invOutVol":0,"inv.FastChgWatts":0,"inv.inputWatts":0,"inv.standbyMins":0,"inv.chgPauseFlag":0,"inv.acInFreq":0,"inv.dischargeType":0,"inv.invOutAmp":0,"inv.sysVer":67174714}}
2024-09-06 09:24:44.241 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed inv state: standbyMins value 0
2024-09-06 09:24:45.053 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"params":{"uploadEn":1,"launchSetType":0,"bsmLaunchDate":1725607485,"resetFlag":0,"sn":"0000000000000000"},"from":"iOS","lang":"de-de","id":"485003007","moduleSn":"R611ZEB5XF1D1931","moduleType":2,"operateType":"getBmsInfo","version":"1.0"}
2024-09-06 09:24:46.868 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372275684082176,"version":"1.0","timestamp":1725607486,"moduleType":"1","params":{"pd.usb1Watts":0,"pd.qcUsb1Watts":0,"pd.wattsInSum":0,"pd.qcUsb2Watts":0,"pd.ext3p8Port":0,"pd.lcdOffSec":300,"pd.standbyMin":30,"pd.extRj45Port":0,"pd.beepMode":0,"pd.remainTime":3805,"pd.typec2Watts":0,"pd.carWatts":0,"pd.ext4p8Port":0,"pd.brightLevel":100,"pd.chgDsgState":0,"pd.typec1Watts":0,"pd.usb2Watts":0,"pd.dcOutState":0,"pd.soc":87,"pd.carState":0,"pd.wattsOutSum":0}}
2024-09-06 09:24:46.877 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: ext3p8Port value 0
2024-09-06 09:24:46.883 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: extRj45Port value 0
2024-09-06 09:24:46.888 - debug: ecoflow-mqtt.0 (52802) station update .pd.remainTime 5999 -> 3805
2024-09-06 09:24:46.903 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: ext4p8Port value 0
2024-09-06 09:24:47.248 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372283809497228,"version":"1.0","timestamp":1725607487,"moduleType":"3","params":{"inv.fanState":0,"inv.cfgAcEnabled":1,"inv.cfgAcXboost":0,"inv.cfgAcWorkMode":0,"inv.invType":0,"inv.SlowChgWatts":0,"inv.acDipSwitch":0,"inv.FastChgWatts":0,"inv.invOutVol":229696,"inv.inputWatts":0,"inv.outputWatts":0,"inv.errCode":0,"inv.standbyMins":0,"inv.chgPauseFlag":0,"inv.invOutFreq":50,"inv.dischargeType":0,"inv.chargerType":0,"inv.sysVer":67174714}}
2024-09-06 09:24:47.255 - debug: ecoflow-mqtt.0 (52802) station update .inv.cfgAcEnabled false -> true
2024-09-06 09:24:47.262 - info: ecoflow-mqtt.0 (52802) state ecoflow-mqtt.0.R611ZEB5XF1D1931.inv.cfgAcEnabled changed: true (ack = true)
2024-09-06 09:24:47.316 - debug: ecoflow-mqtt.0 (52802) station update .inv.invOutVol 0 -> 229.696
2024-09-06 09:24:47.325 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed inv state: standbyMins value 0
2024-09-06 09:24:47.330 - debug: ecoflow-mqtt.0 (52802) station update .inv.invOutFreq 0 -> 50
2024-09-06 09:24:50.159 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372309776040010,"version":"1.0","timestamp":1725607490,"moduleType":"3","params":{"inv.fanState":0,"inv.cfgAcEnabled":1,"inv.cfgAcXboost":0,"inv.cfgAcWorkMode":0,"inv.invType":0,"inv.SlowChgWatts":0,"inv.acDipSwitch":0,"inv.FastChgWatts":0,"inv.invOutVol":230229,"inv.inputWatts":0,"inv.outputWatts":0,"inv.errCode":0,"inv.standbyMins":0,"inv.chgPauseFlag":0,"inv.dischargeType":0,"inv.chargerType":0,"inv.sysVer":67174714}}
2024-09-06 09:24:50.174 - debug: ecoflow-mqtt.0 (52802) station update .inv.invOutVol 229.696 -> 230.229
2024-09-06 09:24:50.184 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed inv state: standbyMins value 0
2024-09-06 09:24:50.423 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372309579301113,"version":"1.0","timestamp":1725607490,"moduleType":"2","params":{"bms_bmsStatus.sysVer":50397534,"bms_bmsStatus.openBmsIdx":1,"bms_bmsStatus.num":0,"bms_bmsStatus.minCellVol":3290,"bms_bmsStatus.f32ShowSoc":87.04,"bms_bmsStatus.bmsFault":0,"bms_bmsStatus.soc":87,"bms_bmsStatus.outputWatts":14,"bms_bmsStatus.errCode":0,"bms_bmsStatus.maxCellVol":3290,"bms_bmsStatus.inputWatts":0,"bms_bmsStatus.type":1,"bms_bmsStatus.remainCap":15654,"bms_bmsStatus.remainTime":0,"bms_bmsStatus.tagChgAmp":20000}}
2024-09-06 09:24:50.431 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.minCellVol 3.293 -> 3.29
2024-09-06 09:24:50.441 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.outputWatts 0 -> 1.4000000000000001
2024-09-06 09:24:50.449 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.maxCellVol 3.293 -> 3.29
2024-09-06 09:24:50.456 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.inputWatts 0.1 -> 0
2024-09-06 09:24:50.463 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.remainCap 15656 -> 15654
2024-09-06 09:24:51.278 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"params":{"resetFlag":0,"launchSetType":0,"sn":"0000000000000000","uploadEn":1,"bsmLaunchDate":1725607491},"from":"iOS","lang":"de-de","id":"491246351","moduleSn":"R611ZEB5XF1D1931","moduleType":2,"operateType":"getBmsInfo","version":"1.0"}
2024-09-06 09:24:53.187 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372335545843817,"version":"1.0","timestamp":1725607493,"moduleType":"3","params":{"inv.fanState":0,"inv.cfgAcEnabled":1,"inv.cfgAcXboost":0,"inv.cfgAcWorkMode":0,"inv.invType":0,"inv.SlowChgWatts":0,"inv.acDipSwitch":0,"inv.FastChgWatts":0,"inv.invOutVol":229297,"inv.inputWatts":0,"inv.outputWatts":0,"inv.errCode":0,"inv.standbyMins":0,"inv.chgPauseFlag":0,"inv.dischargeType":0,"inv.chargerType":0,"inv.sysVer":67174714}}
2024-09-06 09:24:53.202 - debug: ecoflow-mqtt.0 (52802) station update .inv.invOutVol 230.229 -> 229.297
2024-09-06 09:24:53.215 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed inv state: standbyMins value 0
2024-09-06 09:24:55.499 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"params":{"enabled":0,"out_freq":255,"out_voltage":4294967295,"xboost":255},"from":"iOS","lang":"de-de","id":"495468919","moduleSn":"R611ZEB5XF1D1931","moduleType":5,"operateType":"acOutCfg","version":"1.0"}
2024-09-06 09:24:55.649 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set_reply] -> set w/o params{"id":495468919,"version":"1.0","operateType":"acOutCfg","moduleType":5,"time":512252,"code":"0","data":{"ack":0}}
2024-09-06 09:24:55.849 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372351428624865,"version":"1.0","timestamp":1725607495,"moduleType":"5","params":{"mppt.carState":0,"mppt.dischargeType":0,"mppt.faultCode":4096,"mppt.carOutWatts":0,"mppt.dc24vState":0,"mppt.cfgAcXboost":1,"mppt.cfgAcEnabled":0,"mppt.chgType":0,"mppt.outWatts":0,"mppt.beepState":0,"mppt.swVer":50397534,"mppt.cfgChgType":0,"mppt.chgPauseFlag":0,"mppt.dcdc12vWatts":0,"mppt.acStandbyMins":30,"mppt.powStandbyMin":30,"mppt.carStandbyMin":0,"mppt.inWatts":0,"mppt.cfgChgWatts":150,"mppt.scrStandbyMin":1800}}
2024-09-06 09:24:55.858 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed mppt state: dischargeType value 0
2024-09-06 09:24:55.867 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed mppt state: cfgAcXboost value 1
2024-09-06 09:24:55.868 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed mppt state: cfgAcEnabled value 0
2024-09-06 09:24:55.869 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372350832247272,"version":"1.0","timestamp":1725607495,"moduleType":"1","params":{"pd.icoBytes":[0,0,0,0,128,0,0,0,0,0,0,0,0,0],"pd.usb1Watts":0,"pd.qcUsb1Watts":0,"pd.wattsInSum":0,"pd.qcUsb2Watts":0,"pd.ext3p8Port":0,"pd.lcdOffSec":300,"pd.standbyMin":30,"pd.extRj45Port":0,"pd.beepMode":0,"pd.remainTime":1619,"pd.typec2Watts":0,"pd.carWatts":0,"pd.ext4p8Port":0,"pd.brightLevel":100,"pd.chgDsgState":0,"pd.typec1Watts":0,"pd.usb2Watts":0,"pd.dcOutState":0,"pd.soc":87,"pd.carState":0,"pd.wattsOutSum":0}}
2024-09-06 09:24:55.918 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed mppt state: beepState value 0
2024-09-06 09:24:55.931 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: ext3p8Port value 0
2024-09-06 09:24:55.976 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed mppt state: acStandbyMins value 30
2024-09-06 09:24:55.977 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed mppt state: powStandbyMin value 30
2024-09-06 09:24:56.021 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: extRj45Port value 0
2024-09-06 09:24:56.022 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed mppt state: cfgChgWatts value 150
2024-09-06 09:24:56.023 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed mppt state: scrStandbyMin value 1800
2024-09-06 09:24:56.029 - debug: ecoflow-mqtt.0 (52802) station update .pd.remainTime 3805 -> 1619
2024-09-06 09:24:56.080 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: ext4p8Port value 0
2024-09-06 09:24:56.159 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372361315647576,"version":"1.0","timestamp":1725607496,"moduleType":"3","params":{"inv.fanState":0,"inv.cfgAcEnabled":0,"inv.cfgAcXboost":0,"inv.cfgAcWorkMode":0,"inv.invType":0,"inv.SlowChgWatts":0,"inv.acDipSwitch":0,"inv.FastChgWatts":0,"inv.invOutVol":229294,"inv.inputWatts":0,"inv.outputWatts":0,"inv.errCode":0,"inv.standbyMins":0,"inv.chgPauseFlag":0,"inv.dischargeType":0,"inv.chargerType":0,"inv.sysVer":67174714}}
2024-09-06 09:24:56.165 - debug: ecoflow-mqtt.0 (52802) station update .inv.cfgAcEnabled true -> false
2024-09-06 09:24:56.171 - info: ecoflow-mqtt.0 (52802) state ecoflow-mqtt.0.R611ZEB5XF1D1931.inv.cfgAcEnabled changed: false (ack = true)
2024-09-06 09:24:56.185 - debug: ecoflow-mqtt.0 (52802) station update .inv.invOutVol 229.297 -> 229.294
2024-09-06 09:24:56.199 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed inv state: standbyMins value 0
2024-09-06 09:24:57.024 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"params":{"uploadEn":1,"resetFlag":0,"sn":"0000000000000000","bsmLaunchDate":1725607496,"launchSetType":0},"from":"iOS","lang":"de-de","id":"496990726","moduleSn":"R611ZEB5XF1D1931","moduleType":2,"operateType":"getBmsInfo","version":"1.0"}
2024-09-06 09:24:59.126 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372385191985232,"version":"1.0","timestamp":1725607499,"moduleType":"3","params":{"inv.fanState":0,"inv.cfgAcEnabled":0,"inv.cfgAcXboost":0,"inv.cfgAcWorkMode":0,"inv.invType":0,"inv.SlowChgWatts":0,"inv.acDipSwitch":0,"inv.FastChgWatts":0,"inv.invOutVol":0,"inv.inputWatts":0,"inv.outputWatts":0,"inv.errCode":0,"inv.standbyMins":0,"inv.chgPauseFlag":0,"inv.invOutFreq":0,"inv.dischargeType":0,"inv.chargerType":0,"inv.sysVer":67174714}}
2024-09-06 09:24:59.139 - debug: ecoflow-mqtt.0 (52802) station update .inv.invOutVol 229.294 -> 0
2024-09-06 09:24:59.149 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed inv state: standbyMins value 0
2024-09-06 09:24:59.153 - debug: ecoflow-mqtt.0 (52802) station update .inv.invOutFreq 50 -> 0
2024-09-06 09:24:59.642 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"params":{},"from":"iOS","lang":"de-de","id":"499611271","moduleSn":"R611ZEB5XF1D1931","moduleType":1,"operateType":"getAllTaskCfg","version":"1.0"}
2024-09-06 09:24:59.947 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set_reply] -> set w/o params{"id":499611271,"version":"1.0","operateType":"getAllTaskCfg","moduleType":1,"time":516442,"code":"0","data":{"general":{"taskSavedNum":0,"conflictItem":[128],"taskMaxNum":6,"productType":71},"timeTask":{"taskCfgs":[{"taskIndex":0,"week":4,"timeScale":[0,0,0,0,0,0,0,0,0,255,255,255,63,0,0,0,0,0],"year":2024,"isCfg":0,"type":0,"isEnable":0,"sec":0,"taskPrior":0,"min":0,"timeParam":1036419,"month":4,"hour":0,"timeMode":0,"day":3},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255}],"totalTaskNum":0}}}
2024-09-06 09:25:00.871 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372395478647274,"version":"1.0","timestamp":1725607500,"moduleType":"1","params":{"pd.usb1Watts":0,"pd.qcUsb1Watts":0,"pd.wattsInSum":0,"pd.qcUsb2Watts":0,"pd.ext3p8Port":0,"pd.lcdOffSec":300,"pd.standbyMin":30,"pd.extRj45Port":0,"pd.beepMode":0,"pd.remainTime":1755,"pd.typec2Watts":0,"pd.carWatts":0,"pd.ext4p8Port":0,"pd.brightLevel":100,"pd.chgDsgState":0,"pd.typec1Watts":0,"pd.usb2Watts":0,"pd.dcOutState":0,"pd.soc":87,"pd.carState":0,"pd.wattsOutSum":0}}
2024-09-06 09:25:00.883 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: ext3p8Port value 0
2024-09-06 09:25:00.889 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: extRj45Port value 0
2024-09-06 09:25:00.893 - debug: ecoflow-mqtt.0 (52802) station update .pd.remainTime 1619 -> 1755
2024-09-06 09:25:00.902 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: ext4p8Port value 0
2024-09-06 09:25:02.046 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"params":{"uploadEn":1,"sn":"0000000000000000","launchSetType":0,"resetFlag":0,"bsmLaunchDate":1725607502},"from":"iOS","lang":"de-de","id":"502012517","moduleSn":"R611ZEB5XF1D1931","moduleType":2,"operateType":"getBmsInfo","version":"1.0"}
2024-09-06 09:25:06.306 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372447214993565,"version":"1.0","timestamp":1725607506,"moduleType":"2","params":{"bms_bmsStatus.sysVer":50397534,"bms_bmsStatus.openBmsIdx":1,"bms_bmsStatus.num":0,"bms_bmsStatus.minCellVol":3292,"bms_bmsStatus.f32ShowSoc":87.03,"bms_bmsStatus.bmsFault":0,"bms_bmsStatus.soc":87,"bms_bmsStatus.outputWatts":0,"bms_bmsStatus.errCode":0,"bms_bmsStatus.maxCellVol":3292,"bms_bmsStatus.inputWatts":1,"bms_bmsStatus.type":1,"bms_bmsStatus.remainCap":15653,"bms_bmsStatus.remainTime":0,"bms_bmsStatus.tagChgAmp":20000}}
2024-09-06 09:25:06.323 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.minCellVol 3.29 -> 3.2920000000000003
2024-09-06 09:25:06.335 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.f32ShowSoc 87.04 -> 87.03
2024-09-06 09:25:06.359 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.outputWatts 1.4000000000000001 -> 0
2024-09-06 09:25:06.367 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.maxCellVol 3.29 -> 3.2920000000000003
2024-09-06 09:25:06.374 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.inputWatts 0 -> 0.1
2024-09-06 09:25:06.382 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.remainCap 15654 -> 15653
2024-09-06 09:25:06.911 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372447214993925,"version":"1.0","timestamp":1725607506,"moduleType":"1","params":{"pd.usb1Watts":0,"pd.qcUsb1Watts":0,"pd.wattsInSum":0,"pd.qcUsb2Watts":0,"pd.ext3p8Port":0,"pd.lcdOffSec":300,"pd.standbyMin":30,"pd.extRj45Port":0,"pd.beepMode":0,"pd.remainTime":5999,"pd.typec2Watts":0,"pd.carWatts":0,"pd.ext4p8Port":0,"pd.brightLevel":100,"pd.chgDsgState":0,"pd.typec1Watts":0,"pd.usb2Watts":0,"pd.dcOutState":0,"pd.soc":87,"pd.carState":0,"pd.wattsOutSum":0}}
2024-09-06 09:25:06.929 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: ext3p8Port value 0
2024-09-06 09:25:06.933 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: extRj45Port value 0
2024-09-06 09:25:06.937 - debug: ecoflow-mqtt.0 (52802) station update .pd.remainTime 1755 -> 5999
2024-09-06 09:25:06.945 - debug: ecoflow-mqtt.0 (52802) [store station] R611ZEB5XF1D1931 not processed pd state: ext4p8Port value 0
2024-09-06 09:25:07.469 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"params":{"bsmLaunchDate":1725607507,"uploadEn":1,"launchSetType":0,"sn":"0000000000000000","resetFlag":0},"from":"iOS","lang":"de-de","id":"507437241","moduleSn":"R611ZEB5XF1D1931","moduleType":2,"operateType":"getBmsInfo","version":"1.0"}
2024-09-06 09:25:13.600 - info: ecoflow-mqtt.0 (52802) state ecoflow-mqtt.0.R611ZEB5XF1D1931.inv.cfgAcEnabled changed: true (ack = false)
2024-09-06 09:25:13.601 - info: ecoflow-mqtt.0 (52802) (ack=false) ->cmd : channel inv state cfgAcEnabled
2024-09-06 09:25:13.606 - debug: ecoflow-mqtt.0 (52802) prep cmd R611ZEB5XF1D1931 delta2max cfgAcEnabled true {"from":"Android","lang":"en-us","id":"238075216","moduleType":3,"operateType":"acOutCfg","version":"1.0","params":{"enabled":1},"moduleSn":"R611ZEB5XF1D1931"}
2024-09-06 09:25:13.606 - debug: ecoflow-mqtt.0 (52802) publish /app/1772580463883280385/R611ZEB5XF1D1931/thing/property/set
2024-09-06 09:25:13.606 - debug: ecoflow-mqtt.0 (52802) publish {"from":"Android","lang":"en-us","id":"238075216","moduleType":3,"operateType":"acOutCfg","version":"1.0","params":{"enabled":1},"moduleSn":"R611ZEB5XF1D1931"}
2024-09-06 09:25:13.607 - debug: ecoflow-mqtt.0 (52802) Message succesfully published.R611ZEB5XF1D1931 ../..set
2024-09-06 09:25:13.622 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"from":"Android","lang":"en-us","id":"238075216","moduleType":3,"operateType":"acOutCfg","version":"1.0","params":{"enabled":1},"moduleSn":"R611ZEB5XF1D1931"}
2024-09-06 09:25:19.643 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set] -> key:undefined {"params":{},"from":"iOS","lang":"de-de","id":"519611340","moduleSn":"R611ZEB5XF1D1931","moduleType":1,"operateType":"getAllTaskCfg","version":"1.0"}
2024-09-06 09:25:19.916 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [set_reply] -> set w/o params{"id":519611340,"version":"1.0","operateType":"getAllTaskCfg","moduleType":1,"time":536412,"code":"0","data":{"general":{"taskSavedNum":0,"conflictItem":[128],"taskMaxNum":6,"productType":71},"timeTask":{"taskCfgs":[{"taskIndex":0,"week":4,"timeScale":[0,0,0,0,0,0,0,0,0,255,255,255,63,0,0,0,0,0],"year":2024,"isCfg":0,"type":0,"isEnable":0,"sec":0,"taskPrior":0,"min":0,"timeParam":1036419,"month":4,"hour":0,"timeMode":0,"day":3},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255},{"taskIndex":255,"week":255,"timeScale":[255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],"year":65535,"isCfg":255,"type":255,"isEnable":0,"sec":255,"taskPrior":255,"min":255,"timeParam":4294967295,"month":255,"hour":255,"timeMode":255,"day":255}],"totalTaskNum":0}}}
2024-09-06 09:25:22.188 - debug: ecoflow-mqtt.0 (52802) [JSON] R611ZEB5XF1D1931 [update] -> {"addr":0,"cmdFunc":0,"cmdId":0,"id":1811372584653946959,"version":"1.0","timestamp":1725607522,"moduleType":"2","params":{"bms_bmsStatus.errCode":0,"bms_bmsStatus.outputWatts":0,"bms_bmsStatus.inputWatts":0,"bms_bmsStatus.type":1,"bms_bmsStatus.sysVer":50397534,"bms_bmsStatus.openBmsIdx":1,"bms_bmsStatus.num":0,"bms_bmsStatus.remainTime":0,"bms_bmsStatus.f32ShowSoc":87.03,"bms_bmsStatus.tagChgAmp":20000,"bms_bmsStatus.bmsFault":0,"bms_bmsStatus.soc":87}}
2024-09-06 09:25:22.195 - debug: ecoflow-mqtt.0 (52802) station update .bmsMaster.inputWatts 0.1 -> 0


Add the possibility to specify a custom JsonSerializerOptions in TypeSenseClient

This pull request enhances the TypesenseClient by introducing the ability to specify custom JsonSerializerOptions in its constructor.
Motivation
This addition addresses the need to configure polymorphism in scenarios where attribute annotations are impractical or impossible. Microsoft doc link
In many complex projects, especially those involving large domain models, cross-assembly hierarchies, or third-party dependencies, configuring polymorphism using attribute annotations becomes challenging or infeasible. For such use cases, the contract model approach provides a more flexible solution.
The contract model utilizes a custom DefaultJsonTypeInfoResolver subclass to dynamically provide polymorphic configuration per type. This allows for precise and flexible polymorphic serialization configurations. Here is an example for Microsoft documentation:
public class PolymorphicTypeResolver : DefaultJsonTypeInfoResolver
{
    public override JsonTypeInfo GetTypeInfo(Type type, JsonSerializerOptions options)
    {
        JsonTypeInfo jsonTypeInfo = base.GetTypeInfo(type, options);

        Type basePointType = typeof(BasePoint);
        if (jsonTypeInfo.Type == basePointType)
        {
            jsonTypeInfo.PolymorphismOptions = new JsonPolymorphismOptions
            {
                TypeDiscriminatorPropertyName = "$point-type",
                IgnoreUnrecognizedTypeDiscriminators = true,
                UnknownDerivedTypeHandling = JsonUnknownDerivedTypeHandling.FailSerialization,
                DerivedTypes =
                {
                    new JsonDerivedType(typeof(ThreeDimensionalPoint), "3d"),
                    new JsonDerivedType(typeof(FourDimensionalPoint), "4d")
                }
            };
        }

        return jsonTypeInfo;
    }
}

This resolver can be specified in the JsonSerializerOptions used by TypesenseClient, enabling the necessary polymorphic behavior for complex type hierarchies.

Hi @samihafidiDLW, I'll think about the change over the weekend, and let you know start or mid next week.

Hi @samihafidiDLW, I think it looks fine to me. I might add support so it can be changed when the service is registered in the future.
// Rune


roslaunch: Use as documented environment

in relation to #307
roscore-default: Removing not supported variable in variable
roscore-default: Adding PATH, LD_LIBRARY_PATH and PYTHONPATH
roscore.service: Using /opt/ros/hydro/bin instead of /usr/bin to launch
roscore
You can now install roslaunch-systemd :
opkg install roslaunch-systemd
and start roscore :
systemctl start roscore

:+1:


[Question] Is it possible to use this library without window borders?

I'm trying to mimic the view of a ordinary windows console terminal. I do not want any window "borders".
Think of the Terraria server console, I want to have something like that. (see GIF below)

Where I can receive output from the game server e.g. "Player has joined the server" and allow the user the write commands to console simultaneously.
If worse comes to worse I can settle with having a text field at the bottom for input and a view at top which would display all the incoming messages from the server and messages from the input commands.
Let me know if this library can do something like this, thanks in advance.
Update
I found something called ListView, it seems to be part of what I want for my idea, however I have no idea how to add items to the actual list.
Application.Init();

var listView = new ListView();
var label = new Label("123");
listView.Add(label);

Application.Top.Add(listView);

Application.Run();

The above code does not seem to display the label 123. Although it works when I change ListView to View

You can, the borders are purely part of the existing set of UI views but nothing prevents you from authoring your own views.

See https://github.com/migueldeicaza/gui.cs/issues/519
Until that's implemented, as long as you don't use views derived from Window or FrameView you can have no borders.


quilt.mod.json crash

https://mcpaste.io/549cfa152d718fda
Crashes on quilt latest (1.20.1,  0.20.0-beta.11)
1.15.3 originstweaks

At the first glance on the report you've submitted, it says that you're using an outdated version of quilt,which doesn't support a feature used in the quilt metadata file.
But knowing me I probably messed it up...
I've added a quilt metadata file because someone requested it, but if it causes crashes, I will remove it.
Fabric mods are mostly going to work with the quilt loader as far as I know.

same error

fixed it by removing quilt.mod.json


Get raw bytes of Key

Discussed in https://github.com/kumavale/getch-rs/discussions/12

Originally posted by kumavale September  5, 2023
https://github.com/kumavale/getch-rs/blob/1f1e7fb71e1c91cc5156e37a8240ec2393d4ea6d/src/lib.rs#L32-L75

💡There is no problem in converting Key::Ctrl('z') to &[ ('z' as u8) - b'a' + 1 ] .

Since the sizes are different, it should be to_bytes() -> Vec<u8>


Extract demoUrl to site config

Move the demo over to https://demo.roadie.so because it's deployed with the 1-click Kubernetes charts.

[ ] 301 redirect backstage-demo.roadie.io over to demo.roadie.so

Unrelated to this but There are a couple of icons/emojis not loading for me on the careers page:

@martina-if Even on the production site?
This is what I see in Chrome and Firefox.


Development

Description
Improved and detailed view of courses section of website
Type of change
UI/UX

[x] Bug fix (non-breaking change which fixes an issue)
[x] User Interface
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have npm run format before commiting
[x] I replicated the UI with the Design

ScreenShots (if any)

Do add These banner in assets folder too


APIView - Skip sending notification when user ID is empty

Notification step is triggered even when user Id is empty. Though it will not send any email, it's better to avoid sending request to sendgrid in this case.
Add app insights trace when user email address is not available

This is no longer required since we don't use sendgrid anymore.


fix: apply tsconfig only to matched files

:tada: This PR is included in version 2.5.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[M] Public - Update Back Button

Description:
Need to change the button that currently shows as '<- Facilities' in the Contact info page, and '<- Home' on the Parks page to a button that says 'Back', moved to the bottom-right.
Acceptance Criteria:
[Note: Use 'Given/When/Then' format if it makes sense to. Otherwise, a simple checklist that can be tested.]

[ ] Contact Information Page: Current "Facilities" text is removed and a blue button labeled Back replaces it.
[ ] Button moved to bottom right of the page.
[ ] Back button navigates you back to the parks select a pass type page
[ ] Clicking back button produces a warning for navigating away from this page (see ticket #334)
[ ] Park Page: Current "Home" text button is renamed to "back" and moved to the bottom right.

Figma link: https://www.figma.com/file/2lQW8InOa0lEiUiMeGmeNC/Day-Use-Pass?type=design&node-id=3975%3A17140&mode=design&t=YbmeWNjWNn9tCaMc-1
https://www.figma.com/file/2lQW8InOa0lEiUiMeGmeNC/Day-Use-Pass?type=design&node-id=3980%3A18613&mode=design&t=YbmeWNjWNn9tCaMc-1
Development Checklist:

[ ] Any UT's are updated.

Dependencies

Blocked by
Blocking

Relevant documentation as reference
Definition of Ready

[ ] Acceptance criteria are included
[ ] Wireframes are included (if applicable)
[ ] Design / Solution is accepted by Product Owner (if applicable)
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Definition of Done

In progress:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] UI meets accessibility requirements
[ ] Unit tests are written
[ ] Work is traceable in GitHub
[ ] PR linked to ticket number
[ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment

Code review:

[ ] Code is peer reviewed and has passed CI/CD tests

QA:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Code is potentially shippable to the production environment
[ ] Functional features have been tested and passed by QA
[ ] UI components tested by designer
[ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)

PO Review:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Reviewed and approved by Product Owner

Notes:

Update: Move button to the bottom - evenly spaced - see wireframe: https://www.figma.com/file/2lQW8InOa0lEiUiMeGmeNC/Day-Use-Pass?type=design&node-id=3980%3A18613&mode=design&t=rRuWQGWHaOC5p2HU-1

@danieltruong fyi I have added the Parks page "home" button to be renamed to "Back" and also moved to the bottom right for consistency. CC @JLWade @ndelraye . See teams post for context: https://teams.microsoft.com/l/message/19:7gg3pxzoL-hjZRHvr5ggkjxP9O8cah6SWqiYiz2CD_M1@thread.tacv2/1712858476567?tenantId=6fdb5200-3d0d-4a8a-b036-d3685e359adc&groupId=aadf267c-d6ab-4c8c-9cff-e574713575e6&parentMessageId=1712691088221&teamName=External%3A Team Osprey&channelName=General&createdTime=1712858476567

Tested on TEST: Passed

Verified that the UI has been updated as per the requirement.
Passing to PO review.

working as expected moving to done