Integrate Apache Ratis to help manage Raft status

We have some discussions about the integration of Apache Ratis in RP: https://github.com/apache/iotdb/pull/3939.
Create a new issue here to let more people join.
https://github.com/apache/iotdb/pull/3939#issuecomment-917955815
https://github.com/apache/iotdb/pull/3939#issuecomment-917961701
https://github.com/apache/iotdb/pull/3939#issuecomment-917983405
Update the reasons why I'd like to import a 3rd party Raft library.

First and the important one,  raft implementation in IoTDB can't guarantee the correctness (I mean consensus part, even only for write). We have found and fixed some bugs about Raft and we are not sure the end of this. Just like @LebronAl said, the devil lies in the corner cases. It's very hard for us to construct a systematic UT/IT/Manual tests to ensure the safe properties of Raft. As for performance affect, my understanding is even the fastest vehicle should be saft. And raft is only a small part of system, I think if we can use the 3rd party library properly, performance loss should be very small.

Second, current implementation of Raft mixed together with application logic which is hard to maintain and understand.

Last but not least, apply 3rd party library could release us from detail of Raft and focus on core engine improvement, building IoTDB ecosystem, etc.

Reply https://github.com/apache/iotdb/pull/3939#issuecomment-917983405, @LebronAl

Production-level raft algorithms generally guarantee linearizability, which is the strictest consistency in distributed systems. Our current Raft algorithm may not be complete, so strictly speaking it does not guarantee linearizability, but at the same time it's performance may be better. What would we say if we migrated raft implementation and performance dropped? Furthermore, is linearizability really necessary for OLAP databases like time-series databases?

What do you mean by "strictly speaking it does not guarantee linearizability"? In which case, IoTDB doesn't guarantee the linearizability? In my opinion, it doesn't matter IoTDB or other products, if you are using Raft, that means you need the linearizability which is what raft provided. If IoTDB doesn't guarantee the linearizability, I think it's a bug. Right now, I didn't find any of the case.
I agree that we can simply some aspects of Raft implementation but which won't affect performance much. The main performance improvement relays on the multi-raft support.

At the moment we have Raft implementation and business logic mixed together, but there is a certain amount of performance improvement. For example, we currently put data from multiple storage groups into one Raft group to be executed synchronously. In fact, at the bottom, they can be executed in parallel. So we implemented parallel asynchronous apply optimization so that plans from the same Raft group but different storage groups can be applied in parallel. The performance gains from this optimization are significant. How should we handle this case after we migrate raft implementation? Add parallel apply feature to raft library Or do we change our partitioning pattern so that a Raft group serves only one storage group? Or just let them execute inefficiently?

"For example, we currently put data from multiple storage groups into one Raft group to be executed synchronously."
Could you explain this one more detail?

Add parallel apply feature to raft library Or do we change our partitioning pattern so that a Raft group serves only one storage group?

Application(Raft user) takes care of log apply, so it doesn't matter how Raft implemented.
Finally, in my opinion, current performance main gains from multi-raft support. So it won't affect performance too much after integrate Ratis.

is linearizability really necessary for OLAP databases like time-series databases?

As I see the raft is one consensus algorithm, which may do not have many relations with the linearizability, just put the post[1] for reference.

we currently put data from multiple storage groups into one Raft group to be executed synchronously.

As far as I know, the apply function is user-defined, we can still implement a parallel apply function according to different storage groups in the one raft log.
What is certain is that using a raft library will definitely limit our optimization work compared with the current implementation (mixing the raft framework and business logic), but I think the availability and correctness are far greater than the performance for now.
[1] https://zhuanlan.zhihu.com/p/47117804

As I see the raft is one consensus algorithm, which may do not have many relations with the linearizability, just put the post[1] for reference.

In academic terms, whether it is Raft, Multi-Paxos or Zab, these consensus algorithms exist only for multi-node consensus, and have nothing to do with consistency or storage systems. I admit that.
In engineering, what we call Raft is often combined with replication state machines and storage systems. In this context, the relationship between Raft and linearizability is very large.
Take the TiKV you quoted in the blog for example. For writing, Raft needs to ensure that the log which received the majority of acks can be committed. For reading, Raft needs to use Read-Index or Lease-Read to ensure linearizability. These designs are actually decisive factors affecting performance, and the key lies in whether we need such safety. However, such core logic is likely to be hard-coded in the Raft library and cannot be changed (if it can be changed, you can ignore me). But in fact, for OLAP scenarios, do we really need such a high level of consistency? For example, tdengine's default synchronization strategy is asynchronous replication rather than majority.
For another example, Zookeeper's ZAB algorithm guarantees sequential consistency, which is a slightly weaker than linearizable consistency but still a strong consistency level (refer to the jepsen official website). Then in theory, it has higher performance than the Raft algorithm that guarantees linearizability.

I'm not talking about which solution is better. I just think that since we are talking about refactoring, we should think clearly about the guarantee that the entire data model can provide to the outside world. Because they may often determine the upper bound of performance, and in most cases, these are trade-offs between safety and performance. If we don't need some level of safety, then we can definitely go for better performance.

As far as I know, the apply function is user-defined, we can still implement a parallel apply function according to different storage groups in the one raft log.

In the etcd example, we do have the freedom to handle the commit logs, thanks to their excellent abstraction. In ratis's example, it looks like they only exposed one applyTransaction interface for us to override, and I doubt whether we can implement our parallel asynchronous apply optimizations. Of course, I've just had a glance. This area needs further investigation. I just hope some of our optimizations don't go away after the migration.

What is certain is that using a raft library will definitely limit our optimization work compared with the current implementation (mixing the raft framework and business logic), but I think the availability and correctness are far greater than the performance for now.

If performance drops a little bit after migration, I support it. But if it's a big drop, I think it still needs to be considered very carefully. Of course, a preliminary conclusion can be made after further investigation.

What do you mean by "strictly speaking it does not guarantee linearizability"? In which case, IoTDB doesn't guarantee the linearizability? In my opinion, it doesn't matter IoTDB or other products, if you are using Raft, that means you need the linearizability which is what raft provided. If IoTDB doesn't guarantee the linearizability, I think it's a bug. Right now, I didn't find any of the case.

The devil of consensus lies in the corner case. So let me give you three examples that I know of so far that violate linearizability.

The uncommitted Raft logs are not persisted. Consider a scenario where node A is the leader, nodes B and C are followers, node A synchronizes the log to B and C and gets all acks, then submits and applies the log, and then returns success to the client before the next heartbeat to followers. Then there was a momentary power outage, nodes B and C restarted, and node A restarted slowly. Node B and C's log are empty after restarting and recovering, but they are already a majority, so they can serve the client's read request, then this may violate linearizability. Of course, this is strictly an implementation bug and can be fixed. But even if the bug is fixed, you can see that our raft log's  serialization buffer refers to the implementation of the stand-alone WAL, it does not write to the disk and call async every time a log is written, which ensures that the performance will not be limited by the IOPS of the disk. But this may also cause the corner case mentioned above. This is the trade-off between performance and safety.
In fact, to ensure linearizability Raft uses read-index or lease-read. In our current implementation, direct-read is used for the leader and read-index is used for the follower. This can violate linear consistency when a node outage causes a replacement node to execute the same read request. For more specific examples, you can refer to my blog. Of course, we could also use read-index on the leader, but this would undoubtedly degrade performance.
In fact, Raft's naive implementation guarantees at-least-once semantics, and to ensure linearizability semantics, uuid is generated on the client side and a map is logged on the server side to ensure that each command is executed only once. You can refer to section 6.2 of Raft's PhD thesis and dragonboat's discussion on Zhihu.There is no doubt that such an implementation will also affect performance.

Application(Raft user) takes care of log apply, so it doesn't matter how Raft implemented.

I hope so~Maybe we need to make a detailed investigation on Ratis

The uncommitted Raft logs are not persisted. Consider a scenario where node A is the leader, nodes B and C are followers, node A synchronizes the log to B and C and gets all acks, then submits and applies the log, and then returns success to the client before the next heartbeat to followers. Then there was a momentary power outage, nodes B and C restarted immediately, but node A restarted slowly. Node B and C's log are empty after restarting and recovering, but they are already a majority, so they can serve the client's read request, then this may violate linearizability.

Agree that the case is a bug for IoTDB.

In fact, to ensure linearizability Raft uses read-index or lease-read. In our current implementation, direct-read is used for the leader and read-index is used for the follower. This can violate linearizability when a node outage causes a replacement node to execute the same read request. For more specific examples, you can refer to my blog. Of course, we could also use read-index on the leader, but this would undoubtedly degrade performance.

Sorry that I didn't make the assumption clear. I think we are talking things under IoTDB environment. So I didn't take Read operation into consideration. As you have said, linearization the read is not a regular operation in OLAP system.
And let's go back to Raft library topic. Import the Raft library doesn't mean application needs to sync all operation via the library, it depends on requirement. I don't think IoTDB needs to change current read action process flow after import the library.
And learned a lot from your blog and references, thanks.

In fact, Raft's naive implementation guarantees at-least-once semantics, and to ensure linearizability semantics, uuid is generated on the client side and a map is logged on the server side to ensure that each command is executed only once.

Agree the concept but which is unnecessary under IoTDB or time-order data environment. I think the exactly-only-once requirement here as the actions are not idempotent for all system. But operations in time-order-data or ``most of actions in IoTDB (in my understanding all of actions right now) are idempotent naturally. And again, all of these are in scope of application instead of Raft.

Agree that the case is a bug for IoTDB.

Yes

Of course, this is strictly an implementation bug and can be fixed. But even if the bug is fixed, you can see that our raft log's serialization buffer refers to the implementation of the stand-alone WAL, it does not write to the disk and call async every time a log is written, which ensures that the performance will not be limited by the IOPS of the disk. But this may also cause the corner case mentioned above. This is the trade-off between performance and safety.

But the key sentence is this. Even if the bug is fixed. Should we also call async every time when we flush log? The current implementation is a performance-oriented compromise for us, but it certainly sacrifices security. Strictly speaking, we currently buffer data through user-space buffers, whether standalone wal or raft logs. However, with Ratis, they seem to be caching the data in the operating system's Page cache, and async is determined based on the parameters and load. I think our approach’s performance will be better (because it sacrifices more security than theirs), but I don't know how much of performance difference there is. This is worth exploring.

And let's go back to Raft library topic. Import the Raft library doesn't mean application needs to sync all operation via the library, it depends on requirement. I don't think IoTDB needs to change current read action process flow after import the library.

Hope so. IMO, the more additional code we have to write using these Raft libraries, the more optimization possibilities we have for our scenario, just like with etcd. But with Ratis, I'm not sure yet.

Agree the concept but which is unnecessary under IoTDB or time-order data environment. I think the exactly-only-once requirement here as the actions are not idempotent for all system.

In fact, even if every command is idempotent, as long as the client adds retry logic, it will violate linearizability without filtering as described above... This is a fairly advanced feature, as far as I know, only the Raft library for Dragonboat supports this logic, and I don't think Ratis has done it yet.

Agree that the case is a bug for IoTDB.

Yes

Of course, this is strictly an implementation bug and can be fixed. But even if the bug is fixed, you can see that our raft log's serialization buffer refers to the implementation of the stand-alone WAL, it does not write to the disk and call async every time a log is written, which ensures that the performance will not be limited by the IOPS of the disk. But this may also cause the corner case mentioned above. This is the trade-off between performance and safety.

But the key sentence is this. Even if the bug is fixed. Should we also call async every time when we flush log? The current implementation is a performance-oriented compromise for us, but it certainly sacrifices security. Strictly speaking, we currently buffer data through user-space buffers, whether standalone wal or raft logs. However, with Ratis, they seem to be caching the data in the operating system's Page cache, and async is determined based on the parameters and load. I think our approach’s performance will be better (because it sacrifices more security than theirs), but I don't know how much of performance difference there is. This is worth exploring.

IMO, this depends on what kinds of properties IoTDB'd like to guarantee for user. If IoTDB says, I won't lost any data in any situation, then persist each log every time is required and relative performance lose should be acceptable. But if it's doesn't do such guarantee, then it's OK to do some optimization. Of course, we can make it configurable just like standalone WAL in IoTDB. As I didn't look into Ratis, I'm not sure if it makes this configurable.

And let's go back to Raft library topic. Import the Raft library doesn't mean application needs to sync all operation via the library, it depends on requirement. I don't think IoTDB needs to change current read action process flow after import the library.

Hope so. IMO, the more additional code we have to write using these Raft libraries, the more optimization possibilities we have for our scenario, just like with etcd. But with Ratis, I'm not sure yet.

Agree the concept but which is unnecessary under IoTDB or time-order data environment. I think the exactly-only-once requirement here as the actions are not idempotent for all system.

In fact, even if every command is idempotent, as long as the client adds retry logic, it will violate linearizability without filtering as described above... This is a fairly advanced feature, as far as I know, only the Raft library for Dragonboat supports this logic, and I don't think Ratis has done it yet. So we can forget about this.

I don't understand, on zhihu, it says "proposal id" is generated by client, and filter when do apply(often implemented by State Machine). So I think the retry logic is transparent for raft, the retry operation is new log for raft. Not sure my understanding is right or not.

But the key sentence is this. Even if the bug is fixed. Should we also call async every time when we flush log?

Agree with you, in the IOT world, data may not be as sensitive,maybe we can sacrifice security (in some cases) to improve performance (we can even provide configurations to meet different needs of users).But for now, this approach seems to pose a greater danger (eg. cluster can not be restarted successfully, or enter an unstable state, returning confusing results to the user, etc) in corner cases.
BTW,maybe we should comb through some optimizations to compare.I'm so sorry that I seem to see only that the strategy of flushing to disk has an effect, the impact at the Raft level doesn't seem to be as large as expected.

IMO, this depends on what kinds of properties IoTDB'd like to guarantee for user. If IoTDB says, I won't lost any data in any situation, then persist each log every time is required and relative performance lose should be acceptable. But if it's doesn't do such guarantee, then it's OK to do some optimization. Of course, we can make it configurable just like standalone WAL in IoTDB. As I didn't look into Ratis, I'm not sure if it makes this configurable.

Seems can be configurable. Anyway, Let's speed some time exploring  it.

I don't understand, on zhihu, it says "proposal id" is generated by client, and filter when do apply(often implemented by State Machine). So I think the retry logic is transparent for raft, the retry operation is new log for raft. Not sure my understanding is right or not.

maybe you could read my doc of MIT 6.824 lab3, which is slightly more understandable.

To conclude, let's start by investigating Java implementations of some raft libraries, such as Ratis, Sofajraft, etc.
In the process of exploring, I have come up with four aspects that need to be paid attention to, and you can add more:

How Raft libraries integrate with the state machine: is there a way like etcd to send committed logs back to the upper level for free processing (best so we can do our own optimizations including consistency model considerations)? Or just abstracting the apply interface and letting us override (which may not be very friendly).
Can policies for Raft log persistence be configured: forceSync, batch sync, etc.
Are some common Raft optimizations done: batching/ Pipeline /Async apply, which are very common and effective Raft optimizations.
What was done to support multi-raft: was there any pooling done, etc.? This may be of great help in massive raft groups.

Linearizability consists of two aspects: consensus and query implementation, we may have spent some efforts on consensus, but little on query implementation, and you should not blame one for another. Meanwhile, queries in IoTDB may be very different from those in systems like etcd, and the concern of query implementation could be also different.
Relying on another library for core functionalities is risky. Other projects keep bug fixing and refactoring too, it is hard to say if we can catch up with them after some time point. And it would become very difficult to implement any improvements on it, which may eventually make IoTDB lack of competitiveness, as the most important advantage of current IoTDB lies on its superiour performance, we would completely lose control if the consensus part becomes a bottleneck. Ans should any major bug occur, we will have to wait another team to fix it, because fixing it ourselves will create forks.
Also from my personal point of view, I would not hope IoTDB to just become an integration of libraries, without owning its core techniques, which will make us easily overtaken by those who are more willing to challenge.
Above all, most importantly, before you turn to another method, you should answer the following questions:

What is the problem of the current method, do I have any proof?
Is the new method really better than the current one, how do I show it?
Is switching to the new method a better choice than improving the current one, is it really that easy?

Linearizability consists of two aspects: consensus and query implementation, we may have spent some efforts on consensus, but little on query implementation, and you should not blame one for another. Meanwhile, queries in IoTDB may be very different from those in systems like etcd, and the concern of query implementation could be also different.

Can't agree more.

Relying on another library for core functionalities is risky. Other projects keep bug fixing and refactoring too, it is hard to say if we can catch up with them after some time point. And it would become very difficult to implement any improvements on it, which may eventually make IoTDB lack of competitiveness, as the most important advantage of current IoTDB lies on its superior performance, we would completely lose control if the consensus part becomes a bottleneck. Ans should any major bug occur, we will have to wait another team to fix it, because fixing it ourselves will create forks.

The raft libraries often only provides the ability of consensus on Raft log, it doesn't affect business logic much and doesn't force everything is linearization. With proper 3rd party library, we could have enough flexibility to optimize and improvement performance. The production 3rd party libraries should have been verified by some great productions so that we can believe no major bugs happen.

Also from my personal point of view, I would not hope IoTDB to just become an integration of libraries, without owning its core techniques, which will make us easily overtaken by those who are more willing to challenge.
Above all, most importantly, before you turn to another method, you should answer the following questions:

What is the problem of the current method, do I have any proof?
Updated in description of the issue.
Is the new method really better than the current one, how do I show it?
From view of availability, maintainability and code structure, I think yes, the new method would be better than current one. For performance, I'm not sure as it needs experiment. But I think performance lose will be small or no performance lose. Because current implementation of Raft doesn't apply most of optimizations which has been made in other system such as async append, async apply, etc.
Is switching to the new method a better choice than improving the current one, is it really that easy?
The safety properties is too agile to guarantee without enough tests for Raft. Building up a systematic test cases is really hard and looks is impossible under currently implementation(Raft and Business logic mix together). Of course, integrate the new library means we may change current structure, the effort can be evaluated after investigation.
Being doubtful is good, but solid evidence is more convincing.

No bug for now does not mean no bug forever. And different situations and applications expose different problems. The important thing is building our own verification instead of trusting others just because they have tested on their own cases.
I am more than sure that we will have to face some bugs whatever we use, and if just several bugs would make you lose your heart, I think it is probably not likely you will build any confidence in your own creation, and you may never get near the core of some technologies.
I am not sure about what you mean by async append, but we have async apply. And we are very serious about performance problems as performance is one of the few advantages of IoTDB and why we would want to build our own consensus. Otherwise, why do you think we would bother so much. We want to continue this advantage instead of handing it out to others.
I do not understand why you insist that Raft logic is mixed with business logic, as far as I know, only the implementations of partition table and applier concern how stand-alone IoTDB works, and they are already made interface. Most parts of the cluster module can work without any interference with the standalone part, and can also be tested as any raft implementation.

No bug for now does not mean no bug forever. And different situations and applications expose different problems. The important thing is building our own verification instead of trusting others just because they have tested on their own cases.
I am more than sure that we will have to face some bugs whatever we use, and if just several bugs would make you lose your heart, I think it is probably not likely you will build any confidence in your own creation, and you may never get near the core of some technologies.

I think the discussion out of the scope, let's narrow down the scope to the topic. IMO, IoTDB is a production, when we deliver the production to user, we need to tell user how good/bad are we. It's nothing to do with technologies or confidence. Many production are based on others implementation such as TiKV depends on RocksDB which opensourced by Facebook. Raft library is only a tool, import it could reduce unnecessary works and provide a relative high confidence module to sync data to different node.

I am not sure about what you mean by async append, but we have async apply. And we are very serious about performance problems as performance is one of the few advantages of IoTDB and why we would want to build our own consensus. Otherwise, why do you think we would bother so much. We want to continue this advantage instead of handing it out to others.

Agree that the performance is one of the advantages. But even the fastest vehicle should be safe in my understanding. Do you agree this?
Async append means leader can append log locally and broadcast log parallelly.
For async apply, not sure my understanding is right or not, but according code, I think it's sync in current IoTDB implemenation. The appendEntries acquires lock of logManager until get response which means apply complete. And applyEntries in RaftLogManager is also a sync operation. Correct me if my understanding is wrong.
appendEntries in RaftManager:
private long appendEntries(long prevLogIndex, long prevLogTerm, long leaderCommit, List<Log> logs) {
// ... ignore lines
    synchronized (logManager) {
      long startTime = Timer.Statistic.RAFT_RECEIVER_APPEND_ENTRY.getOperationStartTime();
      resp = logManager.maybeAppend(prevLogIndex, prevLogTerm, leaderCommit, logs);
      Timer.Statistic.RAFT_RECEIVER_APPEND_ENTRY.calOperationCostTimeFromStart(startTime);
      if (resp != -1) {
        if (logger.isDebugEnabled()) {
          logger.debug("{} append a new log list {}, commit to {}", name, logs, leaderCommit);
        }
        resp = Response.RESPONSE_AGREE;
      } else {
        // the incoming log points to an illegal position, reject it
        resp = Response.RESPONSE_LOG_MISMATCH;
      }
    }
    return resp;
  }

// applyEntries in RaftLogManager
  void applyEntries(List<Log> entries) {
    for (Log entry : entries) {
      applyEntry(entry);
    }
  }

  public void applyEntry(Log entry) {
    // For add/remove logs in data groups, this log will be applied immediately when it is
    // appended to the raft log.
    // In this case, it will apply a log that has been applied.
    if (entry.isApplied()) {
      return;
    }
    if (blockAppliedCommitIndex > 0 && entry.getCurrLogIndex() > blockAppliedCommitIndex) {
      blockedUnappliedLogList.add(entry);
      return;
    }
    try {
      logApplier.apply(entry);
    } catch (Exception e) {
      entry.setException(e);
      entry.setApplied(true);
    }
  }

I do not understand why you insist that Raft logic is mixed with business logic, as far as I know, only the implementations of partition table and applier concern how stand-alone IoTDB works, and they are already made interface. Most parts of the cluster module can work without any interference with the standalone part, and can also be tested as any raft implementation.

I think we could have a much clear interface definitions and responsibility boundary if we can refine the abstract of Raft implementation. E.g. DataGroupMember and MetaGroupMember are extend from RaftMember, but RaftMember mainly handles Raft related logic such as appendEntry. But DataGroupMember and MetaGroupMember are handlers of application logic such as query or non-query plans.

And applyEntries in RaftLogManager is also a sync operation. Correct me if my understanding is wrong.

You will see an AsyncDataLogApplier if you go further. And we did a lot more rather than just async apply. And I call it Parallel async apply before, which means data from different storage groups can be applied in parallel. You can check the code again.

Most reliable safety is built on the top of deep knowledge of the techniques you use, not how others say it is safe. Sure a lib it is, but what are "unnecessary works"? Our initial purpose was to create a fully controllable cluster module that will not become a bottleneck in the future. Consensus may be the most important thing above all, and it deserves our primary efforts. It is not JUST a tool, it could be the foundation of the whole cluster module.
Of course safety matters, but how can you assert we can not make it safe? Are we really less capable than those who have written those libs, especially we can integrate the experiences of all of them as they are all open-source. I think this is what open-source is all about: we learn from others instead of we copy from others. After all, open-source or not, you can still use compiled libs from others, while being open-source, you learn from them what are the good practices and bad practices so that you can improve your own.
The sync is used because the client wants a result so we must wait until the end of execution, if the result is not desired, the block can be easily removed to achieve a fully synchronized method.
I am not sure what you mean by a more clear interface. RaftMember provides basic Raft implementation, based on it, MetaGroupMember forms a meta group to manage metadata, DataGroupMember forms data groups to manage data. Raft logic and business logic are obviously separated, and I think it is clear enough. Please specify your problems if any.

I think the current focus is on the following two points:

Can we implement a good and correct raft framework.

The answer must be YES, but WHEN? One year or two? With the development of other time-series databases, such as influxdb_ iox、tdengine、matrixdb. Their market share is increasing. As an industrial product, if they want to have their own competitiveness, they must have the characteristics of rapid iteration and stability. However, over the past year, there is no industrial version of cluster version of IoTDB. From this perspective, I prefer to build a usable and secure distributed IoTDB version first. No matter who uses the raft framework, and I think it is a faster way to integrate one that has been widely used in the industry than to implement it yourself.

How good is the performance of the raft framework implemented by yourself?
As far as we know, the performance improvement of our cluster version is as follows:

async apply；

The query does not follow the raft, and the consistency of the query can be determined according to the configuration.
But as far as I know, the apply function of Apache Ratis framework can be decided by users. Moreover, the read request of Ratis does not follow the raft, so I don't think the performance will degrade much.

What is a competitive product?
A safe, stable and widely used product is a competitive product. If there are no available products for users, what about competitiveness?

You may think it is easier to switch to a new frame than to improve the current one, but it is totally not the case. Implementing a distributed version involves much more than calling some methods in a library. Interface adaption, schema conversion, exception handling, cluster organization, and data distribution... there are so many to do. On the other hand, the problems you face now are just worries, doubts, and lack of tests, instead of major issues that will take months to fix.
The paralleled log execution, controllable log replication dispatching, batching, and some ongoing improvements. You may have missed some of them. And since many of us come from a university lab, we will be able to put more state-of-the-art improvements into it.
SQL Server and Oracle are very safe and stable, though they are nothing about competitiveness in this field. One may speed up to take some share at the early stage, but without its core, it will be soon driven out of the market.

By the way, I checked the recent Jira issues that are related to the cluster module, only to find very, very few of them are related to the consensus implementation. So I sincerely doubt merely changing to another consensus implementation can solve any problem.

You may think it is easier to switch to a new frame than to improve the current one, but it is totally not the case. Implementing a distributed version involves much more than calling some methods in a library. Interface adaption, schema conversion, exception handling, cluster organization, and data distribution... there are so many to do.

+1
The goal for all of us was to make the  cluster module more stable: some poeple felt it was better to use a mature Raft library because Raft was hard to be implemented correctly, but I also observed Kafka writing their own Raft instead of using other Raft libraries. Other people don't feel the need to make big changes right now because they don't seem to have any problems at the moment, but using a great Raft library like etcd frees up the consensus bottleneck of the entire cloud native.
Being pragmatic, we have to admit that even if we decided to use another raft library, it wouldn't have been possible in a month or two. Also, most of the bugs we've fixed so far have nothing to do with consensus. Therefore, the decision to move precipitously requires a great deal of risk.
So I suggest we go in three directions in parallel: research + refactoring + testing.

Research: Follow my list of 5 concerns to see how other libraries are doing; Understanding these things will help us understand the Raft algorithm more deeply. Whether the Raft library is replaced or not, this is better for cluster IoTDB because the people who developed it know more about Raft.

Refactoring: Since we've recently started refactoring cluster code, I thought we could refactor Raft code as well. Ideally, it should be a single module, like Kafka. For anyone who wants to change raft library, this is basically the process of changing library, and  need to do some abstraction to change current Raft algorithm. For those who don't want to change raft library, doing so can improve code readability and make it easier to add more complex tests. After modularization, we can enumerate some performance comparisons and pros and cons before we discuss whether raft libraries need to be replaced. I don't think we would be as divergent as we are now.

Testing: After nearly a year of maintaining cluster modules, I believe that most of the bugs fixed so far have nothing to do with consensus and will show up even replacing raft library. Of course, I'm not saying that the Raft we implemented currently had no bugs, it was probably due to a lack of testing and a lack of production cases. Therefore, I suggest that we can fully test the cluster module from now on, and according to the test results we can make the next step of judgment. In addition, I am currently investigating and designing cluster chaos-test framework. If everything goes well, I will have a chaos testing framework that is easy to deploy at the end of September, and we can also use this framework to test cluster‘s stability. Welcome to join me

Summary different opinions and reorg the content to make things clear.
Current situation of cluster availability

https://github.com/apache/iotdb/pull/3939 The bug is found by reviewing code.
https://github.com/apache/iotdb/pull/3930 The bug is found by error msg in a restart fail case. Actually the error msg has been ignored for a long time because server can start normally in most cases.
https://github.com/apache/iotdb/pull/3848 This is a defensive change after reviewing code.
https://github.com/apache/iotdb/pull/3832 The bug is found in a sever can't start case.

The bugs are find/fixed by us in recent month. Some of the bugs is found by reviewing code and look like obvious and the other are reported in Raft unrelated issue. I have reasons to believe that there are much more bugs we don't know. Some of the bug may cause data lose, as IoTDB is most used in big data scenario, it's hard to feel when a small part of data lost. That's the worst situation, we don't know when that will happen and what result it will cause.
Goal of discussion
Find a way to improve availability of cluster of IoTDB and keep outstanding performance in a short time(2 months around).
Assumption
The assumptions are the base of the discussion. We don't need to discussion on these any more.

Chosen 3rd party library of Raft has been widely used in industry, has high quality and the algorithm is correct in known cases. As has been widely used, I think we could believe known cases are all cases we could ever have.
An application scenario may cause many scenarios in Raft.

How to achieve the goal
Import 3rd party Raft framework
Plan

Abstract proper interfaces for Raft, make it a module gradually .
At same time, we can investigate some 3rd party libraries and find if we can have a proper one.
Import the chosen library to replace our raft module if needed.

Of course,  things are not as easy as said but it's clear. After this, the tests can be focused on application scenarios which are much less than raft scenarios.
Advantages

Doable
Raft correctness is guaranteed
Simplify tests, no UT for Raft

Disadvantages

Maybe lose some performance
Lost control of Raft, update need a relative long term
Can't customize raft to improve performance

Improvement base on current implementation
Plan
??
Advantages

Could customize raft to optimize performance.
Raft update could be done in a short term.

Disadvantages

Correctness of Raft is hard to guarantee.
It's hard to make raft tests complete.

My thought
I don't support the solution that improve current implementation because:

I don't know the current tests for raft are complete or not
I don't know how far we are from to make raft test cases complete

As TiKV implemented all tests of raft in etcd(after it has been stabilized for years) with RUST, if we could do something similar in a short time, I think its OK improve base on current implementation by ourselves. And optimize raft at this stage is not a good idea, please let's make it correct first.
Supplement if I miss anything!

The listed issues concentrate on raft log management, which is already a known issue that needs refactoring, and it only contributes to a small part of the whole raft framework. While there are about 100 issues concerning the usage over raft. It is much more reasonable to think switching to a new framework will cause significantly more issues than fixing the current one.
The tests of raft is merely a small part of the whole system, as the algorithm itself is quite simple and is well explained in the paper. What really matters is how you integrate raft with your own business, which, very unfortunately, cannot be helped no matter what framework you use. So if you think using an existing framework could save a lot of tests, that is not the case.

My suggestion is, please give us a list of things your preferred frameworks used to qualify their raft implementation (tests to be specific). Then we will discuss whether it is easier to add the missing tests or directly using their implementation. I think this is much more convincing than saying "I do not know", "I worry", "I doubt".

Hi folks,
Very glad to see the deep discussion about this topic.
Actually we had several similar discussions in the last 2 years. Even last year, I did not give up trying to use Ratis [1]. However, we finally give up the solution.
Some guys may read the paper "Apache IoTDB 分布式架构设计" [2]. The paper is written in 2019, and at that time, we used sofa-jraft[3], and we should release the cluster version at that time but finally, we gave up. The experience told us using an existing implementation is not as beautiful as we thought.
In that version, I asked many times "why you design classes and codes like this", the answer is always "I have to because of the underlying implementation".
We finally blame the performance problem and architecture scalability problem on the third-part library. I know the conclusion may be not correct, but it is hard to guarantee whether the history will replay again...
What is more important, Raft and multi-raft are not our destinations. We believe in the time series management scenario, Raft is over-heavy. Using an existing implementation will limit us finally.  and I do not want to re-implement the cluster module once again at that time...
I know our implementation may have many bugs and we omit many corner cases now. But it may not be a bad thing. The progress will let us understand the system deeply.
IMO, we really need to:

if we can decouple the implementation, it is better. (But it seems there is few things to do according to Tian Jiang's above opinion)
If we consider others have been fully tested, we can learn their test cases to make our implementation more robost.

The answer must be YES, but WHEN? One year or two?

When writing here, I remember another discussion: when we want to implement the monitoring module for IoTDB, which 3rd library should we use?  micrometer, dropwizard or others? Some of them have rich features but some of them have better performance. So, how to choose? Finally, we decide to extract a framework and let users choose what they want to use.
So, if we can do some refactor and then allow let users to switch the implementation, I can accept that.
But it is hard to convince me to give up our implementation.
[1] https://lists.apache.org/thread.html/3c49bc234415417511226c7032009868f9d3475026adf07e2e41f99f%40<dev.ratis.apache.org>
[2] http://scis.scichina.com/cn/2020/SSI-2019-0189.pdf
[3] https://github.com/sofastack/sofa-jraft

BTW, I always agree to provide a no-bug or no critical bug version to industrial users. It depends on all of your contributions.
I believe we can achieve that if all of us contribute together.

There is also another more practical problem. Both Raft and IoTDB have their own log management, and we aim to combine them or replace one with another. I think state machine safety is more important than consensus safety since breaking consensus requires more than one node to malfunction while a single node failure may break state machine safety, so IoTDB WAL will probably be the core of the final log.
However, the log management is enclosed in other frameworks as it normally does not interfere with the business logic, so it will be extremely hard to achieve the purpose of unifying logs with one of the implementation is hidden behind.

Hi, all
Thanks for all your opinions and discussions.
I'd like to close the discussion in a few days. Based on current implementation I don't think we can integrate 3rd party Raft library and the debate here meaningless right now. But no matter we finally decide to apply 3rd party library or not, I think all of us agree that we should decouple the raft and state machine implementation and improve quality at same time. Although this is very hard as have discussed, but I think we can set the aim and achieve it by small step refactors, new design consideration, etc. New discussion should be arise once there is some plan about the decouple.
Any concerns, please let me know.


pretix: pin bleach at 5.0.1

Otherwise we run into TypeErrors on at least the pages plugin.
ERROR 2024-08-05 15:15:33,302 django.request log Internal Server Error: /mrmcd/2019/page/house-rules/
Traceback (most recent call last):
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
               ^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/django/core/handlers/base.py", line 197, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/pretix/presale/utils.py", line 424, in wrap
    response = func(request=request, *args, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/pretix/presale/utils.py", line 424, in wrap
    response = func(request=request, *args, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/pretix/presale/utils.py", line 424, in wrap
    response = func(request=request, *args, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/django/views/generic/base.py", line 104, in view
    return self.dispatch(request, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/django/views/generic/base.py", line 143, in dispatch
    return handler(request, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/django/views/generic/base.py", line 226, in get
    context = self.get_context_data(**kwargs)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/a9hc321pvz664g5022szqkhark1majxg-python3-3.12.4-env/lib/python3.12/site-packages/pretix_pages/views.py", line 292, in get_context_data
    ctx['content'] = bleach.clean(str(page.text), tags=bleach.ALLOWED_TAGS + [
                                                       ^^^^^^^^^^^^^^^^^^^^^^^
TypeError: unsupported operand type(s) for +: 'frozenset' and 'list'

And a failure to restart pretix-worker (celery), when it complained about redis:
Aug 05 14:53:10 srv2 systemd[1]: Started pretalx asynchronous job runner.
Aug 05 14:53:12 srv2 celery[30931]: ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
Aug 05 14:53:12 srv2 celery[30931]: ┃ ┏━━━━━━━━━━┓  pretalx v2024.1.0                                                                                ┃
Aug 05 14:53:12 srv2 celery[30931]: ┃ ┃  ┌─·──╮  ┃  Settings:                                                                                ┃
Aug 05 14:53:12 srv2 celery[30931]: ┃ ┃  │  O │  ┃  Database:  pretalx (postgresql)                                                                                ┃
Aug 05 14:53:12 srv2 celery[30931]: ┃ ┃  │ ┌──╯  ┃  Logging:   /var/log/pretalx                                                                                ┃
Aug 05 14:53:12 srv2 celery[30931]: ┃ ┃  └─┘     ┃  Root dir:  /nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/pretalx   ┃
Aug 05 14:53:12 srv2 celery[30931]: ┃ ┗━━━┯━┯━━━━┛  Python:    /nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/bin/python3.12                         ┃
Aug 05 14:53:12 srv2 celery[30931]: ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Aug 05 14:53:12 srv2 celery[30931]:
Aug 05 14:53:12 srv2 celery[30931]:  -------------- celery@srv2 v5.4.0 (opalescent)
Aug 05 14:53:12 srv2 celery[30931]: --- ***** -----
Aug 05 14:53:12 srv2 celery[30931]: -- ******* ---- Linux-6.6.44-aarch64-with-glibc2.39 2024-08-05 14:53:12
Aug 05 14:53:12 srv2 celery[30931]: - *** --- * ---
Aug 05 14:53:12 srv2 celery[30931]: - ** ---------- [config]
Aug 05 14:53:12 srv2 celery[30931]: - ** ---------- .> app:         pretalx:0xffff9fca7980
Aug 05 14:53:12 srv2 celery[30931]: - ** ---------- .> transport:   redis+socket:///run/redis-pretalx/redis.sock
Aug 05 14:53:12 srv2 celery[30931]: - ** ---------- .> results:     socket:///run/redis-pretalx/redis.sock
Aug 05 14:53:12 srv2 celery[30931]: - *** --- * --- .> concurrency: 2 (prefork)
Aug 05 14:53:12 srv2 celery[30931]: -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
Aug 05 14:53:12 srv2 celery[30931]: --- ***** -----
Aug 05 14:53:12 srv2 celery[30931]:  -------------- [queues]
Aug 05 14:53:12 srv2 celery[30931]:                 .> celery           exchange=celery(direct) key=celery
Aug 05 14:53:12 srv2 celery[30931]:
Aug 05 14:53:13 srv2 celery[30931]: [2024-08-05 14:53:13,144: WARNING/MainProcess] /nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/worker/consumer/consumer.py:508: CPendingDeprecationWarning: The broker_connection_retry configuration setting will no longer determine
Aug 05 14:53:13 srv2 celery[30931]: whether broker connection retries are made during startup in Celery 6.0 and above.
Aug 05 14:53:13 srv2 celery[30931]: If you wish to retain the existing behavior for retrying connections on startup,
Aug 05 14:53:13 srv2 celery[30931]: you should set broker_connection_retry_on_startup to True.
Aug 05 14:53:13 srv2 celery[30931]:   warnings.warn(
Aug 05 14:53:13 srv2 celery[30931]: [2024-08-05 14:53:13,150: WARNING/MainProcess] /nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/worker/consumer/consumer.py:508: CPendingDeprecationWarning: The broker_connection_retry configuration setting will no longer determine
Aug 05 14:53:13 srv2 celery[30931]: whether broker connection retries are made during startup in Celery 6.0 and above.
Aug 05 14:53:13 srv2 celery[30931]: If you wish to retain the existing behavior for retrying connections on startup,
Aug 05 14:53:13 srv2 celery[30931]: you should set broker_connection_retry_on_startup to True.
Aug 05 14:53:13 srv2 celery[30931]:   warnings.warn(
Aug 05 15:18:03 srv2 celery[30931]: [2024-08-05 15:18:03,709: CRITICAL/MainProcess] Unrecoverable error: ResponseError("MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.")
Aug 05 15:18:03 srv2 celery[30931]: Traceback (most recent call last):
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/worker/worker.py", line 202, in start
Aug 05 15:18:03 srv2 celery[30931]:     self.blueprint.start(self)
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/bootsteps.py", line 116, in start
Aug 05 15:18:03 srv2 celery[30931]:     step.start(parent)
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/bootsteps.py", line 365, in start
Aug 05 15:18:03 srv2 celery[30931]:     return self.obj.start()
Aug 05 15:18:03 srv2 celery[30931]:            ^^^^^^^^^^^^^^^^
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/worker/consumer/consumer.py", line 340, in start
Aug 05 15:18:03 srv2 celery[30931]:     blueprint.start(self)
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/bootsteps.py", line 116, in start
Aug 05 15:18:03 srv2 celery[30931]:     step.start(parent)
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/worker/consumer/consumer.py", line 746, in start
Aug 05 15:18:03 srv2 celery[30931]:     c.loop(*c.loop_args())
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/celery/worker/loops.py", line 97, in asynloop
Aug 05 15:18:03 srv2 celery[30931]:     next(loop)
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/kombu/asynchronous/hub.py", line 373, in create_loop
Aug 05 15:18:03 srv2 celery[30931]:     cb(*cbargs)
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/kombu/transport/redis.py", line 1344, in on_readable
Aug 05 15:18:03 srv2 celery[30931]:     self.cycle.on_readable(fileno)
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/kombu/transport/redis.py", line 569, in on_readable
Aug 05 15:18:03 srv2 celery[30931]:     chan.handlers[type]()
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/kombu/transport/redis.py", line 962, in _brpop_read
Aug 05 15:18:03 srv2 celery[30931]:     dest__item = self.client.parse_response(self.client.connection,
Aug 05 15:18:03 srv2 celery[30931]:                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/redis/client.py", line 562, in parse_response
Aug 05 15:18:03 srv2 celery[30931]:     response = connection.read_response()
Aug 05 15:18:03 srv2 celery[30931]:                ^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 05 15:18:03 srv2 celery[30931]:   File "/nix/store/7l28675h69s087imm1k0ky3d4k0xjzjx-python3-3.12.4-env/lib/python3.12/site-packages/redis/connection.py", line 536, in read_response
Aug 05 15:18:03 srv2 celery[30931]:     raise response
Aug 05 15:18:03 srv2 celery[30931]: redis.exceptions.ResponseError: MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.
Aug 05 15:18:05 srv2 systemd[1]: pretalx-worker.service: Main process exited, code=exited, status=1/FAILURE
Aug 05 15:18:05 srv2 systemd[1]: pretalx-worker.service: Failed with result 'exit-code'.
Aug 05 15:18:05 srv2 systemd[1]: pretalx-worker.service: Consumed 7.012s CPU time, 211.9M memory peak, 21.5M read from disk.

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@e1mo @SuperSandro2000 Had no luck having the zugferd plugin show up in the nav. Can either of you test to confirm?


Create Navigation Bar

Please do work for this task in a branch called issue-1.

[x]  Have the nave bar display the links add data and edit, sign out when logged in

[x] Make the logo take the user to the landing page when not logged in

[x] Make logo take the user to the home page when logged in

[x] remove the login from nav


Byte string conversion

Hi there,
I receive the following bytestring:
b'RFH \x02\x00\x00\x00\xec\x03\x00\x00"\x02\x00\x00\xb8\x04\x00\x00MQSTR   \x00\x00\x00\x00\xb8\x04\x00\x00 \x00\x00\x00jms_text  d\x00\x00\x00 ...'
I want to receive it converted from MQ as a string but I receive the above bytestring.
I used the following coding:
def initialize_mq(self):
self.logger.debug("initialize_mq entered!")
    # Message Descriptor
    self.md = pymqi.MD()

    # Get Message Options
    self.gmo = pymqi.GMO()
    self.gmo.Options = pymqi.CMQC.MQGMO_WAIT | pymqi.CMQC.MQGMO_FAIL_IF_QUIESCING | pymqi.CMQC.MQGMO_CONVERT
    self.gmo.WaitInterval = 5000  # 5 seconds

    self.qmgr = pymqi.connect(self.queue_manager, self.channel, self.conn_info)
    self.queue = pymqi.Queue(self.qmgr, self.queue_name)

    self.logger.debug("initialize_mq left!")

In another method I call:
self.message_text = self.queue.get(None, self.md, self.gmo)
But the conversion seems not to work.
What am I doing wrong?
This is how it looks like in MQ Admin:

Best regards
Ruben Hartenstein

Hi, this issue tracker is for issues with the codebase behind https://pypi.org itself, not the projects hosted on PyPI.
You should report this issue to the tracker for the project in question instead.


fix: kcctl resource remove unnecessary ssh parmeter.

Signed-off-by: lixd<EMAIL_ADDRESS>
What type of PR is this?

/kind flake
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for reviewers:
kcctl resource cmd remove unnecessary ssh parameter,load from deploy-config.yaml

Does this PR introduced a user-facing change?

None

Additional documentation, usage docs, etc.:

/cc @qinyer

/lgtm
/approve


[FZ Editor] new zone added in a custom layout can be unreachable

Create a custom layout, add new zones.
Expected behavior: new zones will always be on screen.
Actual behavior: zones start to be partially of screen and can be fully off screen.

how many is "many"? 10?  100?

how many is "many"? 10? 100?

It depends on the screen size, it can be just 3.

The title / description for this is super vague.
what is 'unreachable'
Is this canvas?  grid style?
what is the repo?
screenshots?

Updated title and description.

Working on a fix for this but wanted some clarification on what the intended behavior is if the zones become unreachable. Should the generated ones start shifted diagonally? On top of each other eventually?

@chenac64 / @SeraphimaZ How does one reproduce the bug?
Is this relevant to only the focus layout?  I can't repro

This is an example of it in the custom layout but I can reproduce it similarly on the focus layout.

Regarding chenac64's post above, there is no warning that notifies users once new zones are off-screen.

@chenac64

Should the generated ones start shifted diagonally? On top of each other eventually?

Use a very small delta for the diagonal shift.
Somewhere we have a hard-coded limit that I think is 64, so if showing 64 will require to be on top of each other that's fine.
Thanks.

@chenac64  thanks for visual, i didn't try that path and now understand.

Make default zone smaller

Suggested solution: Don't do the shift, they should be in dead center overlapping.   Adding in a new zone always is on top.
Why: there will always be someone with a small enough monitor where they will hit this case and someone with a large enough monitor where they will want endless numbers of zones

Implementation 1:

Implementation 2:

@crutkas Just to make sure, what you are looking for is implementation 1?

@crutkas

they should be in dead center overlapping

In that case we need to make sure the zone is not covered by the Editor dialog.
Also since the number is centered in the zone, it be covered by the Editor dialog, not ideal, we may reconsider to place the Editor dialog in a different position so it won't interfere.

something like this?

something like this?

@chenac64 Yup.
@enricogior I just can’t think of a better way. A user can delete the zones if they have too many.

@crutkas @chenac64
I have to be honest here, I don't like the zones being added on top of each other.
A small shift (horizontally and vertically) is a better choice.
When a new zones would be partially outside of the screen, simply restart the process from the same coordinates.

i'm not opposed to that, just repeat the focus style grid, smaller / tighter.  When it would fall off screen, then do overlap.
Correct?

It would look like @ColdTune implementation 2? with smaller delta?

Yes but Honestly seems odd it starts in center and does the diagonal motion
On repeat I would start upper left then and move down vs center.
This is an edge case scenario

@crutkas

I'm not opposed to that, just repeat the focus style grid, smaller / tighter. When it would fall off screen, then do overlap.
Correct?

Yes.

On repeat I would start upper left then and move down vs center.

Agreed.

@chenac64 / @ColdTune does that make sense?  Seems like everyone is in agreement now for behavior

I think we understand the changes that need to be made and will try and submit a PR for the issue


add IsTrait  and IsNotTrait selectors

This patch adds IsTrait  and IsNotTrait selectors.

I'll merge but I'll remove Selector::isNotEnum() since it can be accomplished with Selector::NOT(Selector::isEnum())


[Proposal] Modify 300ms delay when using double tap

When I use DoubleTap and Tap together ，tap will delay 300ms to check it's DoubleTap or not . It doesn't matter on mobile，but in desktop , there is a significant delay when tap fast . I know the reason is kDoubleTapTimeout ms Timer，but it's const. May I  have access to change it , or have any solution to handle click speed ?

flutter --version
Flutter 3.0.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision fb57da5f94 (4 weeks ago) • 2022-05-19 15:50:29 -0700
Engine • revision caaafc5604
Tools • Dart 2.17.1 • DevTools 2.12.2

Hi @toly1994328, Thanks for filing the issue. I will leave this for the team to decide.
https://github.com/flutter/flutter/blob/b29c64b3f9d2c6c4da6f0dfa75136daeb6b86722/packages/flutter/lib/src/gestures/multitap.dart#L355

Are you trying to use a double tap gesture recognizer to simulate a double click recognizer?

Hi Flutter team, Any updates on this issue?

As a workaround you can wrap a GestureDetector with a Listener and handle the onPointerDown as an alternative to the delayed onTap.
Listener(
  onPointerDown: (event) => handleTap(),
  child: GestureDetector(
    onDoubleTap: handleDoubleTap,
    child: ...));

Use with a caution; comes with the side-effects where both a double tap and two taps are registered, but at least there is no delay :)

@kozw I don't understand why this issue and various workarounds still exist.
All @toly1994328 , me and other devs have been asking for a long time is that the Flutter team should provide us a simple way to modify kDoubleTapTimeout. 300ms might be good for mobiles, but for desktop it makes a lot of difference and severely deters user experience.

I'm with you, should be an easy fix

I leave a workaround in case it helps someone:
You can extend from TapGestureRecognizer to declare victory in a shorter period of time by adding your own logic to the  handleEvent method
/// A custom tap gesture recognizer that accepts the gesture
/// after 150 milliseconds instead of 300 milliseconds.
/// This is done to make the gesture detector more responsive
/// than the default one
class _ResponsiveTapGestureRecognizer extends TapGestureRecognizer {
  _ResponsiveTapGestureRecognizer({
    super.debugOwner,
  });

  /// Timer to keep track of the last tap up event
  Timer? _lastTapUpEvent;

  @override
  void handleEvent(PointerEvent event) {
    if (event is PointerDownEvent) {
      _lastTapUpEvent?.cancel();
      _lastTapUpEvent = null;
    }
    if (event is PointerUpEvent) {
      _lastTapUpEvent = Timer(
        ConsumptionConfiguration.durationsToDeclareTap,
        () {
          resolve(GestureDisposition.accepted);
          acceptGesture(event.pointer);
        },
      );
    }
    super.handleEvent(event);
  }
}

Also, besides allowing programmers to customize this value, it should be decreased for Desktop platforms by default, because it leads to a very poor user experience.
Without double tap:
Without double tap
With double tap

GestureRecognizer

@juanmasilf Could you provide an example of how to use it in RawGestureDetector?

I believe this shall be solved on a Flutter level, in my case this code works:
int lastTap = DateTime.now().millisecondsSinceEpoch;
    int consecutiveTaps = 1;
    return GestureDetector(
        onTap: () {
          int now = DateTime.now().millisecondsSinceEpoch;
          if (now - lastTap < 300) {
            consecutiveTaps++;
            if (consecutiveTaps >= 2) {
              onDoubleTapFn();
            }
          } else {
            consecutiveTaps = 1;
            onTapFn();
          }
          lastTap = now;
        },
        child: widget
    );

Bear in mind that onTapFn handler will be called first and then onDoubleTapFn handler will be called second. That's the idea, instead of waiting 300ms for UI before we determine whether to call onTapFn or wait for onDoubleTapFn to call, these two functions are called and it's up to you to prepare your code to deal with the onTapFn call side effects.

I believe this shall be solved on a Flutter level, in my case this code works:
int lastTap = DateTime.now().millisecondsSinceEpoch;
    int consecutiveTaps = 1;
    return GestureDetector(
        onTap: () {
          int now = DateTime.now().millisecondsSinceEpoch;
          if (now - lastTap < 300) {
            consecutiveTaps++;
            if (consecutiveTaps >= 2) {
              onDoubleTapFn();
            }
          } else {
            consecutiveTaps = 1;
            onTapFn();
          }
          lastTap = now;
        },
        child: widget
    );

Bear in mind that onTapFn handler will be called first and then onDoubleTapFn handler will be called second. That's the idea, instead of blocking UI for 300ms in order to determine whether to call onTapFn or wait for onDoubleTapFn to call, these two functions are called and it's up to you to prepare your code to deal with the onTapFn call side effects.

Fantastic idea, I love it.
I had a lot of issues with nested GestureDetectors.
In my case, I never had a single widget with both onTap and onDoubleTap.
Usually, its one parent widget with onDoubleTap, for example, a MessageBubble container.
And child widget with onTap, for example, a list of links in a message.
Now I'm finally able to have both events: onTap for links and onDoubleTap for parent widget, without any delay.
Thanks!

Hey, any progress on this in the last two years?

@margorczynski your solution is the same as GestureDetector with onTap and onDoubleTap
The only difference is that you can specify a timeout

@vizakenjack well you simply modify the Duration value to modify the time window between two single taps and a double tap. The gesture detector doesn't offer that from what I understand as it is hardcoded to 300ms - this is the topic of this issue.

@margorczynski  actually there is another issue.
For example, you have a Message widget with onDoubleTap to reply.
And you have a Link widget as child in Message, with onTap.
And when you tap on that child link, there will be an extra delay because of parent widget.

@margorczynski and @vizakenjack  and others, here is an implementation to separate tap counts, and also configure delay. This should support N taps, and would only call its respective callback:
class MultiTappable extends StatefulWidget {
  final Map<int, VoidCallback> onNTap;
  final int tapThresholdMilliseconds;
  final bool haptic;
  final Widget child;

  const MultiTappable({
    super.key,
    required this.onNTap,
    this.tapThresholdMilliseconds = 200,
    this.haptic = true,
    required this.child,
  });

  @override
  State<MultiTappable> createState() => _MultiTappableState();
}

class _MultiTappableState extends State<MultiTappable> {
  int _taps = 0;
  Timer? _t;

  @override
  Widget build(BuildContext context) {
    return InkWell(
      onTap: () {
        _taps++;
        _t?.cancel();
        _t = Timer(widget.tapThresholdMilliseconds.milliseconds, () {
          if (widget.haptic) HapticFeedback.lightImpact();
          widget.onNTap[_taps]?.call();
          _taps = 0;
        });
      },
      child: widget.child,
    );
  }
}

To use this, it would look something like this:
return MultiTappable(
      onNTap: {
        1: () => print('one'),
        2: () => print('two'),
        //etc...
      },
      child: child,
    );

I think this should also respect the OS settings. In most platforms, the user can configure a Double-Click speed.

Hey flutter team.
Still no updates on this?
While these workarounds can work, it becomes a nuisance when dealing with a library since you have to fork it, modify it, and depend on your own modified version which solely solves this problem. It's obvious that this delay is a massive disadvantage for developers that use the flutter desktop and a 300ms delay is by no means natural for a solid desktop experience.
Thank you!

In my case I didn't need the onDoubleTap at all.   I just didn't want to have to wait the 300ms for the onTap function to be called.  This widget immediately calls onTap when the pointer is lifted (assuming the pointer has moved less than 4 pixels).
class SingleTap extends StatefulWidget {
  final VoidCallback onTap;
  final Widget child;

  const SingleTap({
    super.key,
    required this.onTap,
    required this.child,
  });

  @override
  State<SingleTap> createState() => _SingleTapState();
}

class _SingleTapState extends State<SingleTap> {
  Offset lastPos = Offset.infinite;

  @override
  Widget build(BuildContext context) {
    return Listener(
      onPointerDown: (event) {
        lastPos = event.position;
      },
      onPointerUp: (event) {
        log.info('delta ${(event.position - lastPos).distanceSquared}');
        if ((event.position - lastPos).distanceSquared <= 16) {
          widget.onTap.call();
        }
      },
      child: widget.child,
    );
  }
}

Any Updates on Letting the User specify the delay of the doubleClick?

Any Updates on Letting the User specify the delay of the doubleClick?

I'd say just handle it yourself. It's unclear whether or not they even plan on a fix


285 enhancement csv upload admin portal

Hi @mrchrisadams, as you can see in the files, I've been working on reading a csv file and validating it.
For now I'm stuck on something really simple and I don't know what I'm doing wrong.
It can't find the function validate_csv_file, even though I have declared it.

Hi @mrchrisadams, as you can see in the files, I've been working on reading a csv file and validating it. For now I'm stuck on something really simple and I don't know what I'm doing wrong.
It can't find the function validate_csv_file, even though I have declared it.

Fixed it 👍

[ ] Automatically install Pandas with the pre-build
[ ] Find a way to convert ip ranges (start and ending ip) to a ip network (lib doesn't provide a function for it)

@roald-teunissen can you share some of the error messages you see?

I'm not sure what step I am missing here, I went over almost the same steps as the other pages went through.
Message
Traceback

Hi @mrchrisadams, as promised I've uploaded my work so you can pick it up from here.
I've also added some pretty handy make commands.
Before you start with this, it is important to understand that the link to the uploading page can normally be  shown to admin users. If you use the make commands I've created, you will not have direct access as an admin. This is why I have temporarily placed the button in the list that will always be shown. Please make sure to put this "start_csv_import_button" back into the admin_editable listing.

Thanks @roald-teunissen - and thanks the heads up on the admin_editable bits 👍

Closing this in favour of #296


Revert #2895

Issue and/or context: #2920
cellxgene_census_builder//test_builder.py started failing at #2895:

GHA failure at 7241fef7
GHA success at previous commit ab0a5b59

Originally reported by @ivirshup.
Changes:
Revert #2895 (as well as some bits of #2897 and #2909 that were merged since). test_builder.py passes again with this change.
Notes for Reviewer:
I'm not clear on the significance of including (and now removing) the TimestampRange in soma_array.cc; hoping someone can confirm they understand why it was causing an issue, and that it's fine to (temporarily?) revert.

#2895 was crucial for 1.13.1 -- so we need to deep-dive the consolidate/vacuum failure CZI has been seeing and unrevert this PR before TileDB-SOMA 1.14.0. (I.e. restore 2895, 2897, 2909 and the documented/test-cased bugs they fixed -- and also fix the consolidate/vacuum issue.)

I'm not clear on the significance of including (and now removing) the TimestampRange in soma_array.cc; hoping someone can confirm they understand why it was causing an issue, and that it's fine to (temporarily?) revert.

For arrays with enumeration columns, when we first create the array, we set the schema so that the values are empty. On the first write, we read the dictionary values from the arrow array and then call extend enumeration to write the values. We were encountering an issue where when writing an enumeration to a specified timestamp, the readback values were not maching. The solution is to perform the array schema evolution for extending the enumation at that specified timestamp, rather than at the default current timestamp. However, this seems to have created unintentional buggy side-effects. I'll put this on my list to look at today.


Cool experimenting with template engine

Using handlebars as a template engine is a great job! Maybe you could try and figure out what handlebars does underneath. Only as experiment, if you have time :)

Noooo timee ;(


Negative clients

[2018/11/22 08:12:51:3535] NOTICE: WS closed from <IP_ADDRESS> (localhost), clients: -15

When the program terminates, clients gets decremented by 2. Reloading the tab to restart it only increments it by 1.

This should be resolved on the master branch.


fix(pkg/driverbuilder): fixed docker container output when multiplexed.

What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area pkg
What this PR does / why we need it:
When docker container attach is called on a non-tty terminal, stray characters will appear on screen because the docker SDK uses a custom multiplexing protocol allowing STDOUT and STDERR string to be sent to a single stream.
So, we now check if we are running multiplexed and adapt consequently.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: EXONER4TED, FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [EXONER4TED,FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


[object Object] error message

Navigating to settings shows me this

and does not really tell the end user anything useful. So maybe worth just removing that error message?

How did you get to this error? Just a plain install and going to settings?

Yes.

I tried to reproduce with no luck:

from clean install and simply going to: Configuration / Setting / Storage
from clean install, adding the connection to the server, and simply going to: Configuration / Setting / Storage
from clean install, adding the connection with user authentication to the server, and simply going to: Configuration / Setting / Storage

Can you share setup detail and reproduction steps? I see from the Error message you shared that it's related to remote storage / configuration storage.

What SK permission level does you user have?
Do you have any files in: applicationData/users//kip ?
Do you have any files in: applicationData/global//kip ?

Thanks

nothing in applicationData
cleared browser localStorage
load Kip
configure server url
unlock layout, add one numeric display, lock layout
select Configuration - Settings

You are not authenticating to SK. Just connection with a URL, right?

Security on the server is off.

You mean all options are off? Like so?

Disabling Allow Readonly Access  does give me the same error. It's caused by an Application Data Storage Interface call that fails since Readonly is off and you are not authenticated.
KIP requires either Allow Readonly Access or authenticating with a user, and Application Data Storage Interface to be enabled. Is there a way to check these setting using some remote API call?

No, I mean server's security mechanism is OFF: it has not been enabled. There is no login in the admin ui top right and trying to access security settings gives you the Enable securityscreen.


Segmentor saves PPM in POET format

Do we want to allow creating from paste with different formats? (We save in PTOE format, the correct one)
I'd say no for now, but something to keep in mind.

Ingest this in the paste page, but have a confirmation before we switch it to PTOE format.
On the details page:
Detect POET format, switch to PTOE and add a warning.
Perhaps have a copyable string on the details page.


Carla <IP_ADDRESS>-Multiple Manual Controls not working - Independent Client-Server Configuration

I'm running Carla server in one system and the Python Client in another system. Both are connected to same LAN Network.
I can able to run 1st manual control successfully in the client system. When trying to run 2nd manual control in the client(while 1 is still functional), I'm getting the following error.
RuntimeError: time-out of 2000ms while waiting for the simulator, make sure the simulator is ready and connected to <IP_ADDRESS>:2000   The server could not send the OpenDRIVE (.xodr) file:   Make sure it exists, has the same name of your town, and is correct.
Similar behavior is observed in Custom binaries which are build from the source versions(0.9.7). What could be the possible cause of this issue?

@chandeep11 does this behavior occur also in <IP_ADDRESS>?

@germanros1987  Yes, it occurs in <IP_ADDRESS> too.

@bernatx could you take a look at this and report back?

We tested and we can use more than one manual control. We tested through internet mixing windows and linux and it works also, but sometimes we need to specify a greater timeout to let the client connect to the server. The 2 seconds by default are not enough in some situations, so I advice to set that time bigger to allow for busy networks or internet.
I think that was the problem happened.


Make adam variants more accessible

This PR aims at making each Adam variant easier to initialize intuitively & more accessible.

Sorry for the late response, I'll review it.

I appreciate the comments.

Jenkins, test this please.

Jenkins CI test (for commit 6c3aa8cae64d96660726e8b52b4ffecfb36dbd95, target branch master) succeeded!

LGTM!

Jenkins CI test (for commit 6c3aa8cae64d96660726e8b52b4ffecfb36dbd95, target branch master) failed with status FAILURE.


Problem with IERS Bulletin table

When doing the usual update with download_IERS_A it now throws a load of errors every time we import astroplan. Presumably something's wrong with the table it downloaded.
This is a real problem, given it breaks every script that imports astroplan (and by extension our whole TCS).
>>> import astroplan
Traceback (most recent call last):
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/core.py", line 957, in _convert_vals
    converter_func, converter_type = col.converters[0]
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/martin/.local/lib/python3.5/site-packages/astroplan/__init__.py", line 31, in <module>
    get_IERS_A_or_workaround()
  File "/home/martin/.local/lib/python3.5/site-packages/astroplan/utils.py", line 58, in get_IERS_A_or_workaround
    iers.IERS.iers_table = _get_IERS_A_table()
  File "/home/martin/.local/lib/python3.5/site-packages/astroplan/utils.py", line 92, in _get_IERS_A_table
    table = iers.IERS_Auto.open()
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/utils/iers/iers.py", line 583, in open
    cls.iers_table = cls.read(file=filename)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/utils/iers/iers.py", line 452, in read
    iers_a = Table.read(file, format='cds', readme=readme)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/table/table.py", line 2519, in read
    out = io_registry.read(cls, *args, **kwargs)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/registry.py", line 531, in read
    data = reader(*args, **kwargs)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/connect.py", line 39, in io_read
    return read(filename, format=format, **kwargs)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/ui.py", line 353, in read
    dat = reader.read(table)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/cds.py", line 322, in read
    return super(Cds, self).read(table)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/core.py", line 1202, in read
    table = self.outputter(cols, self.meta)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/core.py", line 988, in __call__
    self._convert_vals(cols)
  File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/core.py", line 973, in _convert_vals
    raise ValueError('Column {} failed to convert: {}'.format(col.name, last_err))
ValueError: Column dX_2000A_A failed to convert: could not convert string to float: '9 521 586'

Perhaps some insight can be gained from astropy/astroplan#5059.
What happens if you download the table from a different mirror?
from astropy.utils import iers
iers.IERS_A_URL = http://toshi.nofs.navy.mil/ser7/finals2000A.all
import astroplan

Didn't work I'm afraid.
It looks like it might be a problem at the USNO end, see the bottom of http://maia.usno.navy.mil/ser7/finals2000A.all with missing data?

Does the function keep backups of the old tables? If there's a problem it would be useful to be able to revert and just deal with the loss of accuracy.

Looks like it might be something wrong with the table format, the number it reports an error on is the first not on a new line

@martinjohndyer – any chance this has resolved with newer table updates?

@bmorris3 Yes it seems to be. Obviously just a problem with the table at the other end, though maybe astropy/astroplan should have some validation function to make the errors a little more obvious what's wrong.

@eteq / @bsipocz  – is there any precedent for doing this elsewhere in astropy?

Hi
I have the same problem. But I don't understand what to do to solve it.
Regards

Why does astroplan keep a copy of the IERS data that is separate from the one managed by astropy.utils.iers?

Why does astroplan keep a copy of the IERS data that is separate from the one managed by astropy.utils.iers?

@bmorris3 we're still struggling with this IERS table so I want to dedicate some time to trying to fix it.  Following up on @lpsinger's comment, if we use an alternate url for download it still doesn't seem to place it in the cache properly.  That is, I can do
from astropy.utils import iers
iers.IERS_A_URL = '<custom_url>'
from astroplan import download_IERS_A
download_IERS_A()

and it will work fine, but if I then import any other module that uses astroplan I will still get a warning about it being out of date. I've looked at the source a little bit but there is some trickery going on with it trying to override things and I haven't had the time to fully dig through it.  Any thoughts would be appreciated!

@wtgee I'm currently at the Extreme Solar Systems conference and will be able respond in detail to your question next week. Sorry for my delay 😄


PreCompiler dont respect name argument

Hi,
I am writing my build script to precompile all handlebars templates. But I have a problem with precompiler, following is my command:
>handlebars "_PartialTemplate.hbs"  --partial --name "PartialTemplate" --extension "hbs"
Output is:
... Handlebars.partials['_PartialTemplate'] = ....
How can I change the name of the template from '_PartialTemplate' to 'PartialTemplate' without renaming my file?
Version:
>handlebars -v
4.0.5
Thanks

The "--name" argument is only used if the template is passed via the "-i" option, so this should work for you:
handlebars  --partial --name "PartialTemplate" -i - <_PartialTemplate.hbs

Can you try that?

I'm closing this issue. Please feel free to add comments if you have more questionss.

Hi @nknapp,
I see, but why file name has priority? It would be great if you could make this argument more useful by allowing it to overwrite the file path.
Thanks

I think the option was never intended to override filenames. It was a necessary option, because there is no other way to provide a partial-name when using the -i option.
Am 26. Februar 2017 09:44:03 MEZ schrieb Soroush<EMAIL_ADDRESS>
Hi @nknapp,
I see, but why file name has priority? It would be great if you could
make this argument more useful by allowing it to overwrite the file
path.
Thanks
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/wycats/handlebars.js/issues/1311#issuecomment-282541735

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.


ISPN-7710 Remote query server module dependency

https://issues.jboss.org/browse/ISPN-7710

Add remote query server dependency to org.infinispan module in server
as optional dependency so that CompatibilityProtoStreamMarshaller can
easily be set in configuration.

As a temporary fix I guess this will do. @anistor @gustavonalle will this be obsoleted by the transcoding work or should we consider moving this marshaller to a separate module ?

I agree, good for now. Yes, it will be obsoleted by transcoding, and my experiment on deploying lucene analyzers and protobuf enitity marshallers to server, if proven successful. That approach can be applied to encoders too. I commented on the devlist, but you'll have to go back to the future to read my reply.

Integrated in master and 9.0.x. thanks @galderz !


[Regression] Apple Color Emoji font missing from the latest intel mac os 13 image

Description
Have two identical ci, https://github.com/kyamagu/skia-python/actions/runs/11829956181
(Sync main of fork with upstream)
https://github.com/HinTak/skia-python/actions/runs/12487829150
The latter fails on Apple Color Emoji font being missing.
Platforms affected

[ ] Azure DevOps
[X] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] Ubuntu 24.04
[ ] macOS 12
[X] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[ ] macOS 14 Arm64
[ ] macOS 15
[ ] macOS 15 Arm64
[ ] Windows Server 2019
[ ] Windows Server 2022
[ ] Windows Server 2025

Image version and build link
Success:
Current runner version: '2.320.0'
Operating System
macOS
13.7.1
22H221
Runner Image
Image: macos-13
Version: 20241108.324
Included Software: https://github.com/actions/runner-images/blob/macos-13/20241108.324/images/macos/macos-13-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/macos-13%2F20241108.324
Runner Image Provisioner
2.0.384.1+6d6c56aa16f1b9c7dd7935df5d63980397e44def
Failure:
Current runner version: '2.321.0'
Operating System
macOS
13.7.2
22H313
Runner Image
Image: macos-13
Version: 20241216.479
Included Software: https://github.com/actions/runner-images/blob/macos-13/20241216.479/images/macos/macos-13-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/macos-13%2F20241216.479
Runner Image Provisioner
2.0.404.1+573eac7f0cc07d6bb82d8b9bf5e1ffa69a554644
Is it regression?
Yes
Expected behavior
The Apple Color Emoji font is exported to be installed.
Actual behavior
Cannot find the Emoji font from the system
Repro steps
See the CI entries.

It appears that between Version: 20241108.324 and Version: 20241216.479 , the Apple Color Emoji font has disappeared / not installed.

Hi @HinTak
We will look into the issue and keep you posted with updates.
Thank You.

@susmitamane looking at the CI logs more carefully, it seems that the regression is specific to python 3.13 (works on 3.10/3.11/3.12)- I.e. skia-python loaded via python 3.13 on Intel mac 13 can't access apple color emoji. Has anything changes between the two images regarding its python 3.13 installation?

Okay, the two runs differ by the python version - it is 3.13.0 in the successful run but 3.13.1 in the broken run.

Hi @HinTak

https://docs.python.org/release/3.13.1/whatsnew/changelog.html.- The skia-python library may rely on Python's internal implementation of iteration or memory management, which could be impacted by Python 3.13.1.

According to our early investigation, they have created some Skia.Iter modifications are causing an error. Please give us more time to investigate it and come back to you with clear inputs.

Thank you.

@susmitamane thanks for your time. The skia.Iter code has not changed for at least 5 years, and the identical code works a few weeks ago (the two ci entry are simply one sync'ing the main of the other). Not sure why 3.13.0 to 3.13.1 on mac os x would break. Anyway, I am due to upgrade to 3.13.1 on my Linux desktop from 3.13.0 on the next reboot, too, so I should be able to tell whether 3.13.1 on Linux is affected.

@susmitamane Just to let you know, I have upgraded python on my linux desktop to 3.13.1 from 3.13.0, and I can reproduce the issue on linux. Looking elsewhere, I think the issue is https://github.com/python/cpython/issues/128161 .

@susmitamane I am 100% sure the issue is https://github.com/python/cpython/issues/128161 ; I shall let you to decide whether to close this, or leave this open so that other people having 3.13.0 to 3.13.1 problems can see an answer.

Hi @HinTak,
This issue appears to be related to Python, and since you have already created a new issue in the official Python repository, we will close this one as it is not directly related to macOS images.
Thank you! If you encounter any issues specifically related to macOS images, please feel free to reach out to us.

@susmitamane it turns out to be a python 3.13.0 to 3.13.1 change that breaks a fair number of packages / codes that have been working okay as they are for many years. There is nothing needed to be done on your part, except possibly redirecting other affected people to the filed issue at cpython. Thanks for your time.


Update ShareMenuModule.java

Handle cases when mActivity is null. This fixes the following exception/crashes I periodically get:
NullPointerExceptioncom.meedan.ShareMenuModule in getSharedText
Attempt to invoke virtual method 'android.content.Intent android.app.Activity.getIntent()' on a null object reference
com.meedan.ShareMenuModule in getSharedText at line 35

Merged, thanks!

No problem. Did you release a new version on npm?

Yes, I released a version 2.1.2 with that fix: https://www.npmjs.com/package/react-native-share-menu

Awesome.

great job guys!


Angular 15 Module not found: Error: Can't resolve 'deepmerge-ts'

Angular: 15.0.4
@ngx-translate/core: 14.0.0
ngx-translate-multi-http-loader: 9.3.0
typescript: 4.8.4
ng serve:
./node_modules/ngx-translate-multi-http-loader/fesm2020/ngx-translate-multi-http-loader.mjs:2:0-41 - Error: Module not found: Error: Can't resolve 'deepmerge-ts' in 'node_modules\ngx-translate-multi-http-loader\fesm2020'
package.json:
"dependencies": {
"@angular/animations": "15.0.4",
"@angular/cdk": "15.0.4",
"@angular/common": "15.0.4",
"@angular/compiler": "15.0.4",
"@angular/core": "15.0.4",
"@angular/forms": "15.0.4",
"@angular/material": "15.0.4",
"@angular/platform-browser": "15.0.4",
"@angular/platform-browser-dynamic": "15.0.4",
"@angular/router": "15.0.4",
"@busacca/ng-pick-datetime": "13.0.1",
"@ng-select/ng-select": "10.0.3",
"@ngrx/component-store": "15.1.0",
"@ngx-translate/core": "14.0.0",
"annyang": "2.6.1",
"core-js": "2.6.5",
"ismobilejs": "1.1.1",
"lodash-es": "4.17.21",
"moment": "2.29.1",
"ngx-translate-multi-http-loader": "9.3.0",
"rxjs": "~7.8.0",
"tslib": "2.3.1",
"zone.js": "~0.11.4"
}

@Rezorl This is due to some version of npm not being able to download peerDependencies properly.

I decided to not move it under dependencies since it's considered to be a bad practice


[Question] Disabling lava lakes

Hi! From what I read, this should also work for the lava lake feature, am I right? If so, could you explain me how to do it? Starting on the name of the same feature, which I have no clue what it is... And I would replace the lava blocks with the default terrain block for each biome and the same with the stone blocks that surround the lakes. Maybe this is too much, but with a little info I could try to experiment with it. Thank you n_n

You need the "configured feature" identifier, which is minecraft:lake_lava for lava lakes, so it would be something like:
no_lava_lake => minecraft:lake_lava
no_lava_lake:
minecraft:lava -> minecraft:grass_block
minecraft:stone -> minecraft:grass_block

The problem is that lake_lava is used for both surface and underground lava pools, so replacing the lava with grass would also generate grass underground. Moreover, replacing stone with grass would generate grass on top of grass, which would look ugly until the bottom grass is converted to dirt.
It's just not the right mod for what you're trying to do.

Well, thank you for telling me! I hate those pesky ones generating on the surface. I still really like your mod, gives lots of personalization <3


Document FHIR->FHIR transform capabilities via tests

User Story

As a developer on ReportStream writing FHIR->FHIR transforms,
I want to refer to automated tests that document the different features of FHIR->FHIR transforms,
so that I can understand the full extent of the FHIR-FHIR transforms.
Description/Use Case

We should document the different features and capabilities of the FHIR->FHIR transforms for other developers to reference. A good way to do this is to write tests that test specific features or capabilities of the transforms. As we add new features to the transforms, we should write new tests.
Risks/Impacts/Considerations

Dev Notes

Acceptance Criteria

[ ] Features of FHIR->FHIR transforms understood and documented via test

Hey team! Please add your planning poker estimate with Zenhub @arnejduranovic @jack-h-wang @jalbinson @JessicaWNava @JFU-NAVA-PBC @jimmyfagan @mkalish @thetaurean

This was handled as part of #15169


re-start restoration workers when restarting the application

Issue Number

#484
Overview

[ ] I have made sure to restart a worker for each known wallet when restarting the wallet server

Comments

I have not yet find a nice & easy way to test this :thinking:  ...

Perhaps any test would be handy?

ah, ok - just read the comment in description...

I have not yet find a nice & easy way to test this..

I have not yet find a nice & easy way to test this

Maybe just looking at the logs after restarting the server? (similarly to logging tests in #474 )


Restructure and initial contents on docs

Restructure and initial contents on docs

Codecov Report
Base: 89.56% // Head: 89.56% // No change to project coverage :thumbsup:

Coverage data is based on head (205d095) compared to base (0cc603b).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #173   +/-   ##
=======================================
  Coverage   89.56%   89.56%
=======================================
  Files          69       69
  Lines        5206     5206
=======================================
  Hits         4663     4663
  Misses        543      543

Flag
Coverage Δ

unittests
89.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.