PubSub integration crashing while reading headers

Hi. I just encountered problem with pubsub integration while it's reading headers of message.
I'm using
    def springGcpVersion = "1.0.0.M2"
    compile("org.springframework.cloud:spring-cloud-gcp-pubsub:$springGcpVersion")
    compile("org.springframework.cloud:spring-cloud-gcp-starter-pubsub:$springGcpVersion")
    compile 'org.springframework.integration:spring-integration-core:5.0.1.RELEASE'

That's message payload from debug
GenericMessage [payload={"challengeId":"XXXXXXXX","RANDOM1":"RANOM","RANDOM2":"SOMETHING","trackingId":"5aXq7iERovyuW4wCdPzxDm","messageType":"SELF"}, headers={spanId=2d9ca7abceb4eda6, spanTraceId=5a8452550ce2c1d353acf05d17aa1147, nativeHeaders={spanTraceId=[5a8452550ce2c1d353acf05d17aa1147], spanId=[2d9ca7abceb4eda6], spanSampled=[0]}, messageSent=true, id=fe942721-1efb-b7ec-854b-cf340c22e5b2, spanSampled=0, gcp_pub_sub_acknowledgement=com.google.cloud.pubsub.v1.MessageDispatcher$3@7871f13d, contentType=text/plain;charset=UTF-8, timestamp=1518622869581}]

And that's error value and stacktrace from debug view
ex = {ClassCastException@11779} "java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map"
 detailMessage = "java.lang.String cannot be cast to java.util.Map"
 cause = {ClassCastException@11779} "java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map"
 stackTrace = {StackTraceElement[37]@11794}
 suppressedExceptions = {Collections$UnmodifiableRandomAccessList@11387}  size = 0

org.springframework.messaging.handler.annotation.support.HeaderMethodArgumentResolver.getNativeHeaders(HeaderMethodArgumentResolver.java:98)
org.springframework.messaging.handler.annotation.support.HeaderMethodArgumentResolver.getNativeHeaderValue(HeaderMethodArgumentResolver.java:85)
org.springframework.messaging.handler.annotation.support.HeaderMethodArgumentResolver.resolveArgumentInternal(HeaderMethodArgumentResolver.java:69)
org.springframework.messaging.handler.annotation.support.AbstractNamedValueMethodArgumentResolver.resolveArgument(AbstractNamedValueMethodArgumentResolver.java:100)
org.springframework.messaging.handler.invocation.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:116)
org.springframework.messaging.handler.invocation.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:137)
org.springframework.messaging.handler.invocation.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:109)
org.springframework.integration.util.MessagingMethodInvokerHelper$HandlerMethod.invoke(MessagingMethodInvokerHelper.java:1040)
org.springframework.integration.util.MessagingMethodInvokerHelper.invokeHandlerMethod(MessagingMethodInvokerHelper.java:608)
org.springframework.integration.util.MessagingMethodInvokerHelper.processInternal(MessagingMethodInvokerHelper.java:504)
org.springframework.integration.util.MessagingMethodInvokerHelper.process(MessagingMethodInvokerHelper.java:313)
org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:104)
org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:93)
org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:109)
org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:141)
org.springframework.integration.dispatcher.AbstractDispatcher.tryOptimizedDispatch(AbstractDispatcher.java:116)
org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:132)
org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:105)
org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:73)
org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:438)
org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:388)
org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:181)
org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:160)
org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:47)
org.springframework.messaging.core.AbstractMessageSendingTemplate.send(AbstractMessageSendingTemplate.java:108)
org.springframework.integration.endpoint.MessageProducerSupport.sendMessage(MessageProducerSupport.java:197)
org.springframework.cloud.gcp.pubsub.integration.inbound.PubSubInboundChannelAdapter.receiveMessage(PubSubInboundChannelAdapter.java:81)
com.google.cloud.pubsub.v1.MessageDispatcher$4.run(MessageDispatcher.java:405)
java.util.concurrent.Executors$RunnableAdapter.call$$$capture(Executors.java:511)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java)
java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
java.util.concurrent.FutureTask.run(FutureTask.java)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:748)

When removed @Header(GcpHeaders.ACKNOWLEDGEMENT) AckReplyConsumer ackReplyConsumer from method parameter it's not crashing anymore so it's a temporary fix.
Ofc with this need to use AUTO ack mode.

@Mistic92 ,
Tell me, please, why stack trace is so abnormal?
Looks like not Java...
It's hard to read to determine the root of cause.
May we have a standard Java stack trace, please?

I had to copy it via Intellij debug view because at log there was only message without stacktrace.
Ok I found normal stacktrace
org.springframework.messaging.MessageHandlingException: nested exception is java.lang.ClassCastException
	at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:107)
	at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:93)
	at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:109)
	at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:141)
	at org.springframework.integration.dispatcher.AbstractDispatcher.tryOptimizedDispatch(AbstractDispatcher.java:116)
	at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:132)
	at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:105)
	at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:73)
	at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:438)
	at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:388)
	at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:181)
	at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:160)
	at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:47)
	at org.springframework.messaging.core.AbstractMessageSendingTemplate.send(AbstractMessageSendingTemplate.java:108)
	at org.springframework.integration.endpoint.MessageProducerSupport.sendMessage(MessageProducerSupport.java:197)
	at org.springframework.cloud.gcp.pubsub.integration.inbound.PubSubInboundChannelAdapter.receiveMessage(PubSubInboundChannelAdapter.java:81)
	at com.google.cloud.pubsub.v1.MessageDispatcher$4.run(MessageDispatcher.java:405)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassCastException: null

May we see how does you message look before that exception?
Sounds strange for now though:
java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map"
 detailMessage = "java.lang.String cannot be cast to java.util.Map
...
org.springframework.messaging.handler.annotation.support.HeaderMethodArgumentResolver.getNativeHeaders(HeaderMethodArgumentResolver.java:98)

is related to the code like:
private Map<String, List<String>> getNativeHeaders(Message<?> message) {
	return (Map<String, List<String>>) message.getHeaders().get(
				NativeMessageHeaderAccessor.NATIVE_HEADERS);
}

So, that gives us only one answer: your message has nativeHeaders header which is a String by type.

payload is the same what I send from another service(removed part of json). I'm not changing any headers.
GenericMessage [payload={"challengeId":"XXXXXXXX","RANDOM1":"RANOM","RANDOM2":"SOMETHING","trackingId":"5aXq7iERovyuW4wCdPzxDm","messageType":"SELF"}, headers={spanId=2d9ca7abceb4eda6, spanTraceId=5a8452550ce2c1d353acf05d17aa1147, nativeHeaders={spanTraceId=[5a8452550ce2c1d353acf05d17aa1147], spanId=[2d9ca7abceb4eda6], spanSampled=[0]}, messageSent=true, id=fe942721-1efb-b7ec-854b-cf340c22e5b2, spanSampled=0, gcp_pub_sub_acknowledgement=com.google.cloud.pubsub.v1.MessageDispatcher$3@7871f13d, contentType=text/plain;charset=UTF-8, timestamp=1518622869581}]

Does it say anything to you?
nativeHeaders={spanTraceId=[5a8452550ce2c1d353acf05d17aa1147], spanId=[2d9ca7abceb4eda6], spanSampled=[0]}

So, this indeed is going to be a JSON on another side.
Not sure how fix it from our side, but I can suggest you to filter (remove) such a header before sending over the network.
I think we may filter it as well, because it's not related to Pub/Sub at all. That's about STOMP protocol:
 * An extension of {@link MessageHeaderAccessor} that also stores and provides read/write
 * access to message headers from an external source -- e.g. a Spring {@link Message}
 * created to represent a STOMP message received from a STOMP client or message broker.
 * Native message headers are kept in a {@code Map<String, List<String>>} under the key
 * {@link #NATIVE_HEADERS}.
 *
 * <p>This class is not intended for direct use but is rather expected to be used
 * indirectly through protocol-specific sub-classes such as
 * {@link org.springframework.messaging.simp.stomp.StompHeaderAccessor StompHeaderAccessor}.
 * Such sub-classes may provide factory methods to translate message headers from
 * an external messaging source (e.g. STOMP) to Spring {@link Message} headers and
 * reversely to translate Spring {@link Message} headers to a message to send to an
 * external source.
 *
 * @author Rossen Stoyanchev
 * @since 4.0
 */
public class NativeMessageHeaderAccessor extends MessageHeaderAccessor {

	public static final String NATIVE_HEADERS = "nativeHeaders";

Hm, I don't know where it's coming from. For sending, I'm also using gcp integration.

I think that is done in the spring-cloud-sleuth. See MessagingTextMap:
else {
	MultiValueMap<String, String> map = new LinkedMultiValueMap<>();
	accessor.setHeader(NativeMessageHeaderAccessor.NATIVE_HEADERS, map);
	map.add(key, value);
}

So, we send it as a Map, but it is seriallized on the Pub/Sub side to JSON I guess and on the other side we don't deserialize it to Map back. Therefore such a ClassCastException issue.
/CC @marcingrzejszczak

If there's a bug in Sleuth can someone file an issue and show a sample how to replicate it please?

No, I don't think that there is some bug, @marcingrzejszczak .
I just want to consult with you if it is OK to send tracing header over the network.
More over you might have met similar problem already. Therefore the question how to deal.
Only the way I see is like to filter all those headers who are not String.
Right now I see this code in the PubSubMessageHandler:
message.getHeaders().forEach(
				(key, value) -> headers.put(key, value.toString()));

This is exactly where we get that Map as a String.
And even if we convert it into a string properly, there is no any hooks how to deserialize it to the Map back on the consumer side.
Well. Maybe as a solution to allow to transfer to the Pub/Sub only primitive types and String per se.
Since Map (or any collection) is not a primitive, we don't transfer it at all.
Thoughts ?

I just want to consult with you if it is OK to send tracing header over the network.

That's absolutely what we need to be doing. We need the tracing headers so that the recipient knows that it should continue the trace

Well. Maybe as a solution to allow to transfer to the Pub/Sub only primitive types and String per se.
Since Map (or any collection) is not a primitive, we don't transfer it at all.

As part of #161, I wanted to support sending objects as header values with Pub/Sub.
Haven't looked at what it takes to get there, or if it's possible, though.

Good to know, @marcingrzejszczak !
Well, let's take a look to the message headers one more time!
headers={
    spanId=2d9ca7abceb4eda6, spanTraceId=5a8452550ce2c1d353acf05d17aa1147,
    nativeHeaders={
                    spanTraceId=[5a8452550ce2c1d353acf05d17aa1147],
                    spanId=[2d9ca7abceb4eda6],
                    spanSampled=[0]},
    messageSent=true,
    id=fe942721-1efb-b7ec-854b-cf340c22e5b2,
    spanSampled=0,
    gcp_pub_sub_acknowledgement=com.google.cloud.pubsub.v1.MessageDispatcher$3@7871f13d,
    contentType=text/plain;charset=UTF-8, timestamp=1518622869581}]

So, looks like we are duplicating tracing headers in the top level and in the nativeHeaders as well.
I see like it is done with the mentioned above MessagingTextMap:
accessor.setHeader(key, value);
...
nativeAccessor.setNativeHeader(key, value);

Why do we do that? Why duplicate?
And I don't see that Sleuth is extracting these tracing headers from that nativeHeaders somehow...
Any explanations, @marcingrzejszczak , please ?
From here I think we are still good to filter this Map nativeHeaders before publishing to Pub/Sub.

@joaoandremartins ,
that issue doesn't looks like related to the ``headersconcern because that one clearly describes thepayloadstory. However the headers typing idea is good as well, but should be tackled in the separate issue. We may borrow the wisdom from Spring Kafka and itsDefaultKafkaHeaderMapperwhere we use Jackson'sObjectMapperto serialize header value and store their original types in the separatespring_json_header_types` header, which is used on the inbound side for the proper deserialization.
Right, that might be the way to go here as well.
Anyway we have several open questions:

As a workaround I suggest to filter the nativeHeaders header before publishing to the Pub/Sub. That is what can be done without any modification to the Framework on the application level already right now. Just because we have all those tracing headers as flattened entries anyway.

Understand why SC-Sleuth uses  nativeHeaders and maybe fix the issue in the project to remove such an overhead.

Provide a quick fix to the PubSubMessageHandler do not send headers if they are not primitives and not strings.

Anything of these can be skipped. I don't insist. But the issue should provide some decision.
Thanks

Why do we do that? Why duplicate?
And I don't see that Sleuth is extracting these tracing headers from that nativeHeaders somehow...
Any explanations, @marcingrzejszczak , please ?

Hmm I don't remember really. Maybe sth with websockets? @dsyer do you remember?

I need to check if it still happens on M3. Also I have a question. What should I see at console trace when I'm using pubsub and on both services I have trace dependency? Should I have one span from both services with subspans or separate? Currently, I have span only from service with api.

Not sure if I understood the question, but I think with the Spring Integration Pub/Sub channel adapters, you would only see a single span.

@Mistic92 ,
The issue isn't closed, therefore there is no any fix or solution for you on the matter.
Not sure how your span relationship question is related to the issue.
Shouldn't better to ask it on Spring Cloud Sleuth project instead ?

Ping again to @dsyer about the native headers. I think you mentioned sth that the duplication is required for websockets but maybe in completely wrong

Yes. Websockets. Whatever we do here has to assume that the native headers might be present probably.

It looks like this line (line 81) is related to the cause: https://github.com/spring-cloud/spring-cloud-gcp/blob/94bce62e3e635e143168dbba30c5ad3951327290/spring-cloud-gcp-pubsub/src/main/java/org/springframework/cloud/gcp/pubsub/integration/inbound/PubSubInboundChannelAdapter.java
The payload is turned into a UTF 8 string it seems, so it makes sense that it can't be cast to a Map later on.

For RC1, is filtering out the nativeHeaders header altogether an acceptable stop-gap?
A reminder that Google Cloud Pub/Sub only supports headers in the Map<String, String> form.
We could think of serializing all outbound headers from Object to String using, e.g., Jackson JSON, and vice-versa for incoming ones.
But that would result in bigger message sizes and, therefore, additional charges for the users.
We could also make that flag-protected but, all in all, it's a feature that warrants some more thinking.

@joaoandremartins
Hello,
we are still seeing this issue after we upgraded the build to RC1. any idea?
thanks a lot
Ming

@mingzhao01 What's the issue you're experiencing? I'm not sure how to interpret that code screenshot.

I found other error for RC1 maybe it's kind of related to this issue.
I have mode set to MANUAL. I don't understand this line is set to byte[].class
https://github.com/spring-cloud/spring-cloud-gcp/blob/abcb52deaff7cc34fef06caa3027db1d8e76caf7/spring-cloud-gcp-pubsub/src/main/java/org/springframework/cloud/gcp/pubsub/integration/inbound/PubSubInboundChannelAdapter.java#L54
2018-07-03 21:25:52.699[pool-15-thread-3] WARN  c.g.c.p.v.MessageDispatcher:[onFailure:153] [ ]-        MessageReceiver failed to processes ack ID: PTdFQV5AEkw2AkRJUytDCypYEU4EISE-MD5FU0RQBhYsXUZIUTcZCGhRDk9eIz81IChFFyMpAgJjXV8fYmhcXHUHUAsddyljIWMMRlAIRVl-d2s5MmlfWnAAVQ8RdHlkc2teFSnftZfnuY4iZh89WBJLLD5-, the message will be nacked.
org.springframework.cloud.gcp.pubsub.core.PubSubException: Sending Spring message failed.; nested exception is org.springframework.cloud.gcp.pubsub.support.converter.PubSubMessageConversionException: JSON deserialization of an object of type [B failed.; nested exception is com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `byte[]` out of START_OBJECT token
 at [Source: (byte[])"{"challengeId":"031c2986-7d6f-49b5-957d-95cc09246638","trackingId":"34185c20590c2ab96dbc3691269a57c6"}"; line: 1, column: 1]
	at org.springframework.cloud.gcp.pubsub.integration.inbound.PubSubInboundChannelAdapter.receiveMessage(PubSubInboundChannelAdapter.java:88)
	at com.google.cloud.pubsub.v1.MessageDispatcher$4.run(MessageDispatcher.java:403)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: org.springframework.cloud.gcp.pubsub.support.converter.PubSubMessageConversionException: JSON deserialization of an object of type [B failed.; nested exception is com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `byte[]` out of START_OBJECT token
 at [Source: (byte[])"{"challengeId":"031c2986-7d6f-49b5-957d-95cc09246638","trackingId":"34185c20590c2ab96dbc3691269a57c6"}"; line: 1, column: 1]
	at org.springframework.cloud.gcp.pubsub.support.converter.JacksonPubSubMessageConverter.fromPubSubMessage(JacksonPubSubMessageConverter.java:74)
	at org.springframework.cloud.gcp.pubsub.integration.inbound.PubSubInboundChannelAdapter.receiveMessage(PubSubInboundChannelAdapter.java:80)
	... 8 common frames omitted
Caused by: com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `byte[]` out of START_OBJECT token
 at [Source: (byte[])"{"challengeId":"031c2986-7d6f-49b5-957d-95cc09246638","trackingId":"34185c20590c2ab96dbc3691269a57c6"}"; line: 1, column: 1]
	at com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63)
	at com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1342)
	at com.fasterxml.jackson.databind.DeserializationContext.handleUnexpectedToken(DeserializationContext.java:1138)
	at com.fasterxml.jackson.databind.DeserializationContext.handleUnexpectedToken(DeserializationContext.java:1092)
	at com.fasterxml.jackson.databind.deser.std.PrimitiveArrayDeserializers.handleNonArray(PrimitiveArrayDeserializers.java:240)
	at com.fasterxml.jackson.databind.deser.std.PrimitiveArrayDeserializers$ByteDeser.deserialize(PrimitiveArrayDeserializers.java:498)
	at com.fasterxml.jackson.databind.deser.std.PrimitiveArrayDeserializers$ByteDeser.deserialize(PrimitiveArrayDeserializers.java:446)
	at com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:1611)
	at com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1234)
	at org.springframework.cloud.gcp.pubsub.support.converter.JacksonPubSubMessageConverter.fromPubSubMessage(JacksonPubSubMessageConverter.java:70)
	... 9 common frames omitted

@Mistic92 It looks like your payload type is a JSON string. Since you didn't change the payload type to the desired class, the JacksonPubSubMessageConverter is trying to convert it to the default byte[] and fails.
Do you have a class to represent challengeId and trackingId? Or do you just want your Spring Message<> to contain the JSON as a String?
@artembilan I think we might want to stop automatically configuring the JacksonPubSubMessageConverter. It seems to be creating unexpected behavior for users. It might be better to leave it as a more explicit setting.

@meltsufin I have class for this but I'm using pubsub integration and expecting String which later I'm parsing with Jackson.
Ok I think I found how to setup type and it seems to work :) Thank you.
Is it missing in samples?

@Mistic92 The idea is that we can do the conversion from JSON to your custom payload type automatically in the adapter. So, you don't have to do it separately.
Indeed, since it's such a popular use case, we should have a sample for it.

Yes, this is cool idea and it should be in sample or just mentioned :)
I don't know if this issue is fixed in RC1. I just get this error but message was send from M2 version
2018-07-03 22:33:13.375[pool-15-thread-3] WARN  c.g.c.p.v.MessageDispatcher:[onFailure:153] [ ]-        MessageReceiver failed to processes ack ID: PTdFQV5AEkw2AkRJUytDCypYEU4EISE-MD5FU0RQBhYsXUZIUTcZCGhRDk9eIz81IChFFyMpAgJjXV8fYmhcXHUHUAsddyljIWMMRlAIRVl-d2s5MmlfWnAAVQ8RdHlkc2teFSnftZfnuY4iZh89WBJLLD5-, the message will be nacked.
org.springframework.cloud.gcp.pubsub.core.PubSubException: Sending Spring message failed.; nested exception is org.springframework.messaging.MessageHandlingException: nested exception is java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map, failedMessage=GenericMessage [payload=FinisherMessage(challengeId=031c2986-7d6f-49b5-957d-95cc09246638, trackingId=34185c20590c2ab96dbc3691269a57c6), headers={spanTraceId=5b3aab684aa80bdee670404a0fd24d5b, spanId=0e97644f56a49b63, gcp_pubsub_acknowledgement=com.google.cloud.pubsub.v1.MessageDispatcher$3@76a4c1e, nativeHeaders={spanTraceId=[5b3aab684aa80bdee670404a0fd24d5b], spanId=[0e97644f56a49b63], spanSampled=[0]}, messageSent=true, id=4e132ac8-c5d8-7c5e-4c17-40e450aab74c, spanSampled=0, timestamp=1530649993375}]
	at org.springframework.cloud.gcp.pubsub.integration.inbound.PubSubInboundChannelAdapter.receiveMessage(PubSubInboundChannelAdapter.java:88)
	at com.google.cloud.pubsub.v1.MessageDispatcher$4.run(MessageDispatcher.java:403)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: org.springframework.messaging.MessageHandlingException: nested exception is java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map
	at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:107)
	at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:93)
	at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:109)
	at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:158)
	at org.springframework.integration.dispatcher.AbstractDispatcher.tryOptimizedDispatch(AbstractDispatcher.java:116)
	at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:132)
	at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:105)
	at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:73)
	at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:445)
	at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:394)
	at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:181)
	at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:160)
	at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:47)
	at org.springframework.messaging.core.AbstractMessageSendingTemplate.send(AbstractMessageSendingTemplate.java:108)
	at org.springframework.integration.endpoint.MessageProducerSupport.sendMessage(MessageProducerSupport.java:203)
	at org.springframework.cloud.gcp.pubsub.integration.inbound.PubSubInboundChannelAdapter.receiveMessage(PubSubInboundChannelAdapter.java:79)
	... 8 common frames omitted
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map
	at org.springframework.messaging.handler.annotation.support.HeaderMethodArgumentResolver.getNativeHeaders(HeaderMethodArgumentResolver.java:98)
	at org.springframework.messaging.handler.annotation.support.HeaderMethodArgumentResolver.getNativeHeaderValue(HeaderMethodArgumentResolver.java:85)
	at org.springframework.messaging.handler.annotation.support.HeaderMethodArgumentResolver.resolveArgumentInternal(HeaderMethodArgumentResolver.java:69)
	at org.springframework.messaging.handler.annotation.support.AbstractNamedValueMethodArgumentResolver.resolveArgument(AbstractNamedValueMethodArgumentResolver.java:100)
	at org.springframework.messaging.handler.invocation.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:116)
	at org.springframework.messaging.handler.invocation.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:137)
	at org.springframework.messaging.handler.invocation.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:109)
	at org.springframework.integration.util.MessagingMethodInvokerHelper$HandlerMethod.invoke(MessagingMethodInvokerHelper.java:1056)
	at org.springframework.integration.util.MessagingMethodInvokerHelper.invokeHandlerMethod(MessagingMethodInvokerHelper.java:574)
	at org.springframework.integration.util.MessagingMethodInvokerHelper.processInternal(MessagingMethodInvokerHelper.java:468)
	at org.springframework.integration.util.MessagingMethodInvokerHelper.process(MessagingMethodInvokerHelper.java:312)
	at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:104)
	... 23 common frames omitted

@Mistic92 M2 is fairly old now and the Pub/Sub integration has evolved quiet a bit since then. Try M4 or RC1 please.


Add completion for require relative

We currently have completion for regular requires, which search the indexed files based on require paths. We can also provide require_relative completion, which would be a nice improvement.
I think the implementation would be something like this:

First, refactor the current completion so that we're handling CallNode instead of StringNode https://github.com/Shopify/ruby-lsp/blob/e5a2c89b66769a83e218e717fbeeee009d89ed69/lib/ruby_lsp/requests/completion.rb#L58
Then, check if the method call is require and execute the current implementation
If it's require_relative, then we want to

Expand the path given as argument. For example, if we have require_relative "../something/", we need to expand it to the absolute path using Pathname
After we have the absolute path, we need to list all Ruby files available that path to provide as completion suggestions. Likely doing something along the lines of Dir.glob("#{absolute_path}/**/*.rb")

hi @vinistock , can I work on this issue?

hi @vinistock , can I work on this issue?


Page shown when accessing from mobile is too generic

If mobile user goes to explorer.decentraland.org he gets this generic oops screen instead of something with more descriptive copy. Not sure if Romi designed a screen for this case but there is a generic fail screen with a cute sad robot.

Follows the copy suggested by Dave Carr:

[Decentraland logo]
Header:
Decentraland (capitalized ‘D’ and in bold)
Subhead:
UNDER CONSTRUCTION
Body copy:
At present Decentraland cannot be explored on mobile devices. Until we get it up and running, you can explore the Metaverse via desktop.
Keep on top of all technical developments at our blog.

And here we have the cute robot animation made by Shibu:
https://decentralandteam.slack.com/files/U9FSNRC4F/FKH00J56F/sadrobot_404.mp4
Let's use it :)


[region-isolation] Enable region isolation by default with strict-concurrency

I added a disable flag -disable-region-based-isolation-with-strict-concurrency so that we do not need to update the current tests.

NOTE: I am just starting the source combat testing. I am going to add actual usage of disable-region-based-isolation-with-strict-concurrency in a bit.

@swift-ci test source compatibility

Release failure was due to something unrelated that failed in the optimizer.

@swift-ci smoke test

@swift-ci test source compatibility

Just checking in to see where we are

Still no crashes with ToT.

Actually, realized doing this in a different PR that is more up to date.


Add "from sequence number" text box.

Add autoindent check control to MessageForm:

Allow resubmit a message with the same body it was received.
Avoid copying original custom properties when resubmitting if not desired.

Add "from sequence number" text box to ReceiveModelForm:

Allow picking messages from a given sequence number.

Update WindowsAzure.ServiceBus to v5.2.0.

:white_check_mark: Build ServiceBusExplorer 4.2.0-PullRequest0361.118.build.577 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/753746537c by @gabrielgt)

Thank you @SeanFeldman for your comments and quick review.
There are two changes in the UI, and these are the screenshots:
New "autoindent" check:

New "from sequence number" textbox:

I will respond to every comment you made :)

:white_check_mark: Build ServiceBusExplorer 4.2.0-PullRequest0361.119.build.578 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/8bbdcbef45 by @gabrielgt)

:white_check_mark: Build ServiceBusExplorer 4.2.0-PullRequest0361.120.build.580 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/bb84c9ea51 by @gabrielgt)

Hi @SeanFeldman did you check if expected changes have been implemented? Sorry for taking to the thread late, but I was busy in this period, thanks!

@paolosalvatori yes, unrelated change was reverted here: https://github.com/paolosalvatori/ServiceBusExplorer/pull/361/commits/3019291cad7e7104aab4019b03cf1720b77d78e3

So I can safely squash and merge changes @SeanFeldman, right? :)


When accepting a group with a reject and error message should be raised

A independent script returns the below as expected and proves the API is returning what is expect within 2 seconds
~/aims/api/groups/resolutionfeed/2000668/accept
{u'entities': [{u'class': [u'validation'], u'rel': [u'error'], u'properties': {u'severity': u'Reject', u'description': u'AddressableObjectID cant be assigned using the spatial Address object', u'ruleId': u'AIMS: V0027'}}], u'class': [u'error'], u'properties': {u'status': 400, u'reason': u'Bad Request', u'message': u'Validation Errors'}}

The UI does not raise this message

Resolved


Bulk set consent records

In this interim period it will be easier to bulk set consent.

I don't know how big of a deal this is but we iterate through a whole list of consent and set them in the database every time you load V2 consent in android. It felt like it might be faster to just do this in a transaction all at once. https://github.com/xmtp/xmtp-android/pull/297/files#r1759609079
Open to others thoughts if they feel this isn't necessary.


missing parse_origin_form

we need parse_origin_form for HTTP's request-target:
origin-form    = absolute-path [ "?" query ]

See: https://datatracker.ietf.org/doc/html/rfc7230#section-5.3.1

A relative reference that begins with a single slash character is termed an absolute-path reference.  A relative reference that does not begin with a slash character is termed a relative-path reference.


add hide_identity and hide_version parameters, and update the

template to add those parameters to the server: configuration.
default for both variables is true, since there should not really be a need to give that information out to the clients if they ask, the administrator should know what DNS server is running ;)

Looks like it got reverted a commit later? I don't see this in master anymore

Looks there to me.

https://github.com/xaque208/puppet-unbound/commit/df87e30632ecc1dded7dbd9e1acd00dac16649bc
Was removed here.

A fresh clone and running git branch --contains df87e30632ecc1dded7dbd9e1acd00dac16649bc yields an indication that referenced commit is in the master branch.  What am I missing?  There was a messed up commit a while ago that was pretty odd, but I believe that to be resolved.

In df87e30632ecc1dded7dbd9e1acd00dac16649bc, file manifests/init.pp , line number 46 + 47. The $hide_identity and $hide_version variables were removed and never replaced with $unbound::params:: equivalents.

You're right about the missing params from that commit.  That looks to be something that I just overlooked when merging rather than the commit itself missing.  Care to submit a PR to add them back in?


fix: readme

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (8bb54a0) 100.00% compared to head (473fdf5) 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##              master        #9   +/-   ##
===========================================
  Coverage     100.00%   100.00%
  Complexity         5         5
===========================================
  Files              2         2
  Lines             10        10
===========================================
  Hits              10        10

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Update compilerplugin-shaded, ... to 0.10.8

Updates

com.thesamet.scalapb:compilerplugin-shaded
com.thesamet.scalapb:protoc-gen-scala
com.thesamet.scalapb:scalapb-runtime

from 0.10.3 to 0.10.8.
GitHub Release Notes - Changelog - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.thesamet.scalapb" } ]

labels: library-update, semver-patch

Something looks really broken here, closing for now.


HDFS-15568. namenode start failed to start when dfs.namenode.max.snapshot.limit set.

please see https://issues.apache.org/jira/browse/HDFS-15568

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
40m 35s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
32m  7s
trunk passed

+1 :green_heart:
compile
1m 16s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m  8s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 47s
trunk passed

+1 :green_heart:
mvnsite
1m 15s
trunk passed

+1 :green_heart:
shadedclient
17m 51s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 50s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 19s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
3m 13s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
3m 11s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  8s
the patch passed

+1 :green_heart:
compile
1m 11s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javac
1m 11s
the patch passed

+1 :green_heart:
compile
1m  1s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
javac
1m  1s
the patch passed

-0 :warning:
checkstyle
0m 40s
hadoop-hdfs-project/hadoop-hdfs: The patch generated 3 new + 89 unchanged - 0 fixed = 92 total (was 89)

+1 :green_heart:
mvnsite
1m 10s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
15m 27s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 46s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 16s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
3m 27s
the patch passed

_ Other Tests _

-1 :x:
unit
80m 10s
hadoop-hdfs in the patch passed.

-1 :x:
asflicense
0m 35s
The patch generated 4 ASF License warnings.

209m 18s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.sps.TestExternalStoragePolicySatisfier

hadoop.fs.viewfs.TestViewFSOverloadSchemeWithMountTableConfigInHDFS

hadoop.fs.viewfs.TestViewFileSystemHdfs

hadoop.fs.viewfs.TestViewFileSystemLinkMergeSlash

hadoop.hdfs.TestSnapshotCommands

hadoop.fs.viewfs.TestViewFsAtHdfsRoot

hadoop.hdfs.TestFileChecksumCompositeCrc

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2296

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 94a92cfd8c29 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / e5fe3262702

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/1/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/1/testReport/

asflicense
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/1/artifact/out/patch-asflicense-problems.txt

Max. process+thread count
3060 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/1/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

/retest

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 12s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
33m 38s
trunk passed

+1 :green_heart:
compile
1m 16s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m  8s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 47s
trunk passed

+1 :green_heart:
mvnsite
1m 16s
trunk passed

+1 :green_heart:
shadedclient
17m 44s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 50s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 18s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
3m  7s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
3m  5s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  8s
the patch passed

+1 :green_heart:
compile
1m 11s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javac
1m 11s
the patch passed

+1 :green_heart:
compile
1m  2s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
javac
1m  2s
the patch passed

-0 :warning:
checkstyle
0m 43s
hadoop-hdfs-project/hadoop-hdfs: The patch generated 1 new + 89 unchanged - 0 fixed = 90 total (was 89)

+1 :green_heart:
mvnsite
1m  8s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
15m 41s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 45s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 16s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
3m 10s
the patch passed

_ Other Tests _

-1 :x:
unit
108m 47s
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 36s
The patch does not generate ASF License warnings.

199m 30s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.sps.TestExternalStoragePolicySatisfier

hadoop.hdfs.TestFileChecksum

hadoop.hdfs.web.TestWebHdfsWithMultipleNameNodes

hadoop.hdfs.TestSnapshotCommands

hadoop.hdfs.server.namenode.ha.TestBootstrapAliasmap

hadoop.hdfs.server.namenode.ha.TestInitializeSharedEdits

hadoop.hdfs.server.namenode.snapshot.TestSnapshotManager

hadoop.hdfs.TestFileChecksumCompositeCrc

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2296

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux aa36c5473309 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 89428f142fe

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/2/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/2/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/2/testReport/

Max. process+thread count
2712 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/2/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 10s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
31m 51s
trunk passed

+1 :green_heart:
compile
1m 17s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m 10s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 50s
trunk passed

+1 :green_heart:
mvnsite
1m 15s
trunk passed

+1 :green_heart:
shadedclient
17m 51s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 51s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 25s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
3m  8s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
3m  6s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  8s
the patch passed

+1 :green_heart:
compile
1m 11s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javac
1m 11s
the patch passed

+1 :green_heart:
compile
1m  4s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
javac
1m  4s
the patch passed

+1 :green_heart:
checkstyle
0m 41s
the patch passed

+1 :green_heart:
mvnsite
1m 10s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
15m 34s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 45s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 16s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
3m 11s
the patch passed

_ Other Tests _

-1 :x:
unit
112m 34s
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 37s
The patch does not generate ASF License warnings.

201m 39s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.sps.TestExternalStoragePolicySatisfier

hadoop.hdfs.TestGetFileChecksum

hadoop.hdfs.TestFileChecksumCompositeCrc

hadoop.hdfs.server.namenode.snapshot.TestSnapshotManager

hadoop.hdfs.TestBlockStoragePolicy

hadoop.hdfs.TestSnapshotCommands

hadoop.hdfs.TestFileChecksum

hadoop.hdfs.TestDFSOutputStream

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2296

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux b21b996bec02 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 2a6fdcedeb4

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/3/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/3/testReport/

Max. process+thread count
2682 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2296/3/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

retest

/retest

Thanks @szetszwo and @goiri for the review.


[Monitor][Query] Regen with DPG

Swagger file updated so that the metrics client and query client are generated separately.
Removes dependency on msrest.
Generated models were removed and hand-crafted models were adjusted to compensated.
LogsQueryClient and MetricsQueryClient were updated to use the updated code.
The LogsQueryError class now includes an instance variable for error details.

/azp run python - monitor - tests

/azp run python - monitor - tests


Troubles updating GUI

Upon opening the GUI I am ask whether or not i would like to update. Whether I press yes or no it starts updating anyways, which leads to one of two outcomes.The first one being it freezes mid update and does not continue. The second one being  the update hits 100% and then comes up with the error "There was an issue running dataserv-client, make sure you have Microsoft .NET Framework installed and try again. If the issue persists let us know on github." I have tried reinstalling the Microsoft .net framework, but no luck. I am running Windows 7 professional.

already  solved, need microsoft c++ redistubte packe x86

Dublicate: https://github.com/Storj/driveshare-gui/issues/69
Workaround for now:
Microsoft Visual C++ 2010 Redistributable Package 32bit for dataserv-client 2.1.4
Next dataserv-client release needs Microsoft Visual C++ 2008 Redistributable Package 32bit.


Version 1.4.0 do not want to save anything

Describe your idea:
Version 1.3.3 and ver 1.3.5 save all, but ver 1.4.0 do not save files on disk

@skavengeer I can't reproduce this issue. Did anyone else have this issue?

@skavengeer I can't reproduce this issue. Do any errors appear in logs? Did anyone else have this issue?

I can reproduce this issue. There are no messages in logs.

same, I'm using windows 11, jadx-gui-1.4.0-with-jre-win.zip, nothing in logs


Newcomer LIGO developers can build and test applications with smart contracts. "Hello World" contrct and companion dapp can be compiled, deployed and tested

As a newcomer developer, I want to build, deploy and test my application and smart contracts so that I can easily get started with a Tezos project.
Acceptance Criteria

[ ] #456
[ ] Scaffolded testing
[ ] Deploy to Sandbox
[ ] Interact with dapp
[ ] Interact with Sanbox

-[ ] Hello Taco Simplification:

[ ] Remove Ligo native tests
[ ] Change source code to reduce number of steps to taqify app
[ ] Update directory name

Closing: Redundant issue


JVM default encoding is not set to UTF-8

What happened?
Docker image prepared by paketo-buildpacks/bellsoft-liberica using spring-boot-maven-plugin in version 2.3.12.RELEASE is not using UTF-8 as default encoding. UTF-8 encoding is most common encoding type and should be used as a default one.

What were you attempting to do?
Integrate java spring-boot application with azure blob storage using com.azure.azure-storage-blob in version 12.6.0 and list blobs which under the hood query azure backend for xml response.

What did you expect to happen?
Default encoding of JVM is set to UTF-8 because it's most common encoding.

What was the actual behavior? Please provide log output, if possible.
Request listing blob return xml with BOM for UTF-8 ï»¿<?xml version="1.0" encoding="utf-8"?> which is then incorrectly parsed.

Below log is from spring boot application at runtime (not from buildpack build process).
Caused by: com.azure.core.exception.HttpResponseException: HTTP response has a malformed body.
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.lambda$decode$1(HttpResponseBodyDecoder.java:95)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:118)
	at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onNext(FluxDoFinally.java:123)
	at reactor.core.publisher.FluxHandle$HandleSubscriber.onNext(FluxHandle.java:112)
	at reactor.core.publisher.FluxMap$MapConditionalSubscriber.onNext(FluxMap.java:213)
	at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onNext(FluxDoFinally.java:123)
	at reactor.core.publisher.FluxHandleFuseable$HandleFuseableSubscriber.onNext(FluxHandleFuseable.java:178)
	at reactor.core.publisher.FluxContextStart$ContextStartSubscriber.onNext(FluxContextStart.java:96)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1812)
	at reactor.core.publisher.MonoCollectList$MonoCollectListSubscriber.onComplete(MonoCollectList.java:121)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.onComplete(FluxPeek.java:252)
	at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:136)
	at reactor.netty.channel.FluxReceive.onInboundComplete(FluxReceive.java:383)
	at reactor.netty.channel.ChannelOperations.onInboundComplete(ChannelOperations.java:373)
	at reactor.netty.channel.ChannelOperations.terminate(ChannelOperations.java:429)
	at reactor.netty.http.client.HttpClientOperations.onInboundNext(HttpClientOperations.java:655)
	at reactor.netty.channel.ChannelOperationsHandler.channelRead(ChannelOperationsHandler.java:96)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
	at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1368)
	at io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1245)
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1282)
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:446)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
	at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	... 1 more
Caused by: com.azure.core.implementation.serializer.MalformedValueException: Unexpected first character (char code 0xEF), not valid in xml document: could be mangled UTF-8 BOM marker. Make sure that the Reader uses correct encoding or pass an InputStream instead
	at com.azure.core.util.serializer.JacksonAdapter.deserialize(JacksonAdapter.java:184)
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.deserializeBody(HttpResponseBodyDecoder.java:176)
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.lambda$decode$1(HttpResponseBodyDecoder.java:88)
	... 46 more
Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected first character (char code 0xEF), not valid in xml document: could be mangled UTF-8 BOM marker. Make sure that the Reader uses correct encoding or pass an InputStream instead
	at com.fasterxml.jackson.dataformat.xml.util.StaxUtil.throwAsParseException(StaxUtil.java:37)
	at com.fasterxml.jackson.dataformat.xml.XmlFactory._createParser(XmlFactory.java:584)
	at com.fasterxml.jackson.dataformat.xml.XmlFactory.createParser(XmlFactory.java:464)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3468)
	at com.azure.core.util.serializer.JacksonAdapter.deserialize(JacksonAdapter.java:179)
	... 48 more
Caused by: com.ctc.wstx.exc.WstxIOException: Unexpected first character (char code 0xEF), not valid in xml document: could be mangled UTF-8 BOM marker. Make sure that the Reader uses correct encoding or pass an InputStream instead
	at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:175)
	at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:573)
	at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:633)
	at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:687)
	at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:350)
	at com.fasterxml.jackson.dataformat.xml.XmlFactory._createParser(XmlFactory.java:582)
	... 51 more

Build Configuration
default spring boot configuration in version boot 2.3.12.RELEASE
<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <layers>
            <enabled>true</enabled>
        </layers>
        <image>
            <name>${docker-image-name}</name>
            <env>
                <BP_JVM_VERSION>${project.java.source}</BP_JVM_VERSION>
            </env>
        </image>
    </configuration>
</plugin>

Problem can be solved by passing JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 but it's not obvious at the beginning
Checklist

[x] I have included log output.
[x] The log output includes an error message.
[ ] I have included steps for reproduction.

I'm not inclined to set this because I think it's more of a concern for an application developer. If the default works, great, but if not I think the application developer should choose what encoding to use.
I'm also concerned about diverging from the default behavior in Java. Java has a defined behavior for how it determines the default character set. It's generally well-known, documented, and easy to search and find information about. If the buildpack changes this default behavior, that could create problems for someone also, someone expecting the default behavior.
As you mentioned, you can set -Dfile.encoding=UTF-8 if you like or you can use these instructions to set the locale which influences the JVMs default decision.
Beyond that, I would say let's keep this issue open and let it gather feedback. If there are enough people interested in the buildpack setting the default character set and none opposing it, then we can revisit making this change.
If you're in favor of this, please 👍. If you think we should keep the JVM default, 👎 . Thanks

@dmikusa-pivotal i can't find it in JVM documentation but i'm pretty sure that default encoding is set based on operating system, user locale running JVM and others. So default encoding other than UTF-8 comes from base docker image, not from JVM itself.

i can't find it in JVM documentation but i'm pretty sure that default encoding is set based on operating system, user locale running JVM and others.

The default behavior of the JVM on Linux is to use the locale. It's in the Javadoc, https://docs.oracle.com/javase/8/docs/api/java/nio/charset/Charset.html and StackOverflow, and other places if you search for "java default character set". As always Baeldung has a great write-up.

So default encoding other than UTF-8 comes from base docker image, not from JVM itself.

Correct, but the buildpack doesn't provide the base image. The buildpack can run on any number of different base images and so the locale could differ depending on the base image. If we set this value in the buildpack and it'll squash the default behavior. That means that the buildpack is doing something unique and potentially unexpected to users (like if you set the locale in your base image and expected it to use that).
Again, I'm not necessarily opposed to changing it. It's a default though, so we have to be particularly careful about changing defaults. Thus I'd like to get feedback before doing it. If this seems to be generally useful, then we can move ahead with it.

I would like to close this out because I don't think we want to have special behavior for the buildpacks. We are also rolling out Java 18 support now, which defaults to UTF-8, and there are also multiple easy fixes if you want to force UTF-8 and are not able to use the latest version.
pack build -e JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 ...

or
pack build -e LANG=en_US.utf8 ...

You could also use the environment-variables buildpack and embed LANG=en_US.utf8 if you don't want to have to set that on build and run.
pack build -e $BPE_DEFAULT_LANG=en_US.utf8 ...

I ended up here, because this doesn't work for native images.
You can find my specific issue here: https://github.com/paketo-buildpacks/native-image/issues/344
Since it's not using a JVM, it's not honoring JAVA_OPTS or JAVA_TOOL_OPTIONS. Or at least not delegating to the container.
Passing them as environment variables to the container also doesn't work, as they're not used in the startup command that calls the native executable.
The only way to work around that is either
docker run imagehere -Dsun.jnu.encoding=UTF-8
or
services:
  janitorr:
    container_name: janitorr
    image: ghcr.io/schaka/janitorr:native-amd64-80-merge
    command: -Dsun.jnu.encoding=UTF-8
    user: 1000:1000


Mark optional questions as optional

These are optional questions but were not marked as such, which will prevent users from being able to mark their service as complete unless they fill-in these optional questions.

:+1:


[$500] Chat - Can't select blockquote between text if text is greater in length.

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open any report
Send a block quote between text with line breaks
Try to select block quote and text by double clicking on the empty space beside texts & block quote
If text is greater in length the block quote is not selectable
If block quote is greater in length the text is not selectable

Expected Result:
The text/block quote should be selectable by double/triple-click.
Actual Result:
The text/block quote is not selectable by double/triple-click.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: v1.3.67-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/115492554/348f3cea-44b9-4500-8838-55ce5e8709d7
https://github.com/Expensify/App/assets/115492554/27dfcd58-8d5e-4009-a680-37562901b6d5
Expensify/Expensify Issue URL:
Issue reported by: @krishna2323
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693936701583489
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01345dccdcf5dee0ea
Upwork Job ID:<PHONE_NUMBER>023347200
Last Price Increase: 2023-09-18

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~019904ef989290e55b
Check the CSS style of the quote message and update it.

@aimane-chnaif could you review the proposal here?

Bump on this @aimane-chnaif

@aimane-chnaif what do you think of this last comment?

Bump @aimane-chnaif

Still waiting on proposals.

@aimane-chnaif - could you please create a Slack thread for what we should do with this one?

Bump @aimane-chnaif - what do you think we should do with this one?

Closing!


Issue/6610 suggest importing module when lookup fails (#6939)

Pull request opened by the merge tool on behalf of #6939

Merged into branches iso6 in 247abaa89a9ac58cb6fc9b8b92291f81f5fb44a0


[Bug]: Fill record field code action and completion item giving partial result for nested records

Description
$subject
When the record is nested and there are record inclusions for nested record the code action and completion item is not giving partial result.
Steps to Reproduce
type T record {
    Foo foo;
};

type AB record {|
    int a;
    int b;
|};

type Foo record {|
    *AB;
    Bar bar;
    Baz baz;
|};

type Bar record {|
    *AB;
|};

type Baz record {|
    *AB;
|};

function fn() {
    T t  = {<CURSOR>};
}

Affected Version(s)
No response
OS, DB, other environment details and versions
No response
Related area
-> Compilation
Related issue(s) (optional)
No response
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response

Duplicate of https://github.com/ballerina-platform/ballerina-lang/issues/42394


Update README.md to update the recommended version of gcc and to put the recommended version of ROOT.

We are now all working with at least gcc 4.4, so I updated the recommended compiler version to the one we are currently using at Duke (gcc4.4.7). I also put which version of ROOT should be used, since WCSim will not work with all versions of ROOT.

Just to be clear, this is a change only to the README file and doesn't affect the code.


Updates geth sync instruction to specify ropsten, updates zeno start …

…command with commit added to log as alright suggested

I was a bit confused about the first command being on the same line as the second  git log -n 1 >> zeno.log & zeno notarise kmdeth), but it seems to work :slightly_smiling_face:. Thanks


Documentation

API docs with redoc or swagger
Developing docs for common features (adding a field)

See https://redocly.github.io/redoc/?url=http://majora.covid19.climb.ac.uk/static/majora.yaml

I initially had a swagger ui interface built into Majora, but it seems more sensible to just serve the YAML statically and point viewers at it. Long term, this would be another huge benefit of using Django REST, but for now, I'm much happier.

#44

#44

I don't like the DRF autodoc fwiw. Hand-rolled YAML for redoc is fine, but actually I think hand-written API github pages was the way to go all along...

I don't like the DRF autodoc fwiw. Hand-rolled YAML for redoc is fine, but actually I think hand-written API github pages was the way to go all along...


Gronsfeld cipher

Let's implement the Gronsfeld cipher.
Relevant package is cz.vse.fis.ws.polyalphabetic.

Done,


can you share the processed movilen dataset or process script?

Great work and implement，can you share the processed movilen dataset or process script?
Thanks!

It has been sent~


Suggestion: implement in special traits ignore half cover

I have seen that in the special traits section of the character sheet, there is an option in the Feats field to ignore the 1/2 and 3/4 cover..... but there is no option for only 1/2.
The thing is that there are certain skills or items, such as the item Wand of war mage (pg 212 DMG) that only ignore 1/2 cover from spell attacks.
It would be interesting to implement the extra option to choose only ignore 1/2 for this kind of special cases.

I don't know if there is any other way to handle this automatically.... xD
I don't know if it is useful, or if it can be done.... the truth is that there are multiple situational occasions.

Option for this has been coded and awaits addition as per https://github.com/trioderegion/dnd5e-helpers/pull/259

And merged.


[bug] Amplify Console Dark Mode bug

my path: https://console.aws.amazon.com/amplify/home?region=us-east-1&code=564f27153040679132a4#/dsw4gfc33xhg7/create/addfrontend/github

Just curious @sw-yx if you are using a specific browser?  I tried this in Chrome and Firefox and it seems to toggle between Light and Dark just fine.

chrome. oh dear i didnt really specify what the bug was did i? Just the white-on-grey "light/dark" text up on the top right.

@sw-yx Thanks for the additional info!  I just tried on chrome incognito and wasn't able to repro:

Maybe you have some custom settings/browser add-ons affecting the text color?

mmh. yeah my browser has been VERY funky around aws in general. no idea whats going on. thanks for confirming.


Add possibility to define custom readinessProbe

[x ] Chart version not bumped (the versions are all bumped and released at the same time)
[x] README.md updated with any new values or changes

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

@mschmidt291 are you able to elaborate on why you need to define a completely custom readiness probe?
The reason I ask is that the existing readiness probe has been written to handle multiple scenarios gracefully, such as initial cluster bootstrapping, rolling restarts, graceful cluster upgrades etc.
By defining a custom readiness probe, a lot of that functionality could end up being broken...

@fatmcgav Oh damn, I actually closed the first PR because of the CLA which was missing. I forgot to write the link down here.
There is a bug in Kuberentes with exec readinessProbes, which results in a very high CPU usage. You can read more about it here: https://github.com/kubernetes/kubernetes/issues/82440 We're currently in the process of moving every deployment which we use away from exec to a tcpProbe or httpProbe. This fixes the high CPU usage.

@mschmidt291 cheers for the link... That's a pretty painful looking bug...
I'll raise this PR internally to see how we want to handle it.
On the surface it's a very trivial change; however as I eluded to above there's a lot of logic built into the existing readinessProbe to support the nuances of running an Elasticsearch cluster on k8s...

jenkins test this please


Multithreading Enhancements

Using a write lock for the port.writes to each display.
Adding some error handling to attempt reconnects to a display if it has been disconnected.
Adding Dummy display config for testing performance without the display communication
Adding some debug logging

I updated the example code and tested with my displays to make sure things are still working.


doc: net: Add websocket and websocket_console to net API docs

Websocket related groups were missing from network API documentation.
Fixes #6779
Signed-off-by: Jukka Rissanen<EMAIL_ADDRESS>

Codecov Report

Merging #6787 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #6787   +/-   ##
=======================================
  Coverage   54.64%   54.64%
=======================================
  Files         447      447
  Lines       42587    42587
  Branches     8040     8040
=======================================
  Hits        23272    23272
  Misses      16084    16084
  Partials     3231     3231

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f77469a...e9252e3. Read the comment docs.


feat(pie-monorepo): DSW-000 updated components to use Lit 3

Describe your changes (can list changeset entries if preferable)
Author Checklist (complete before requesting a review)

[ ] I have performed a self-review of my code
[ ] If it is a core feature, I have added thorough tests
[ ] If it is a PIE Docs change, I have reviewed the Docs site preview
[ ] If it is a component change, I have reviewed the Storybook preview
[ ] If there are visual test updates, I have reviewed them properly before approving

Reviewer checklists (complete before approving)
Reviewer 1

[ ] If it is a PIE Docs change, I have reviewed the PR preview
[ ] If there are visual test updates, I have reviewed them

Reviewer 2

[ ] If it is a PIE Docs change, I have reviewed the PR preview
[ ] If there are visual test updates, I have reviewed them

Closing in favour of this PR! - https://github.com/justeattakeaway/pie/pull/999


Fix sample app package name conflict with Kalendar

Fix #12

Can we  make com.himanshoe.sample.charty please?
Thank you

Done


allow inspectors to be registered for different objects

Subject of the issue
When comparing objects nested in diffable objects (e.g. Hash), it can be difficult to differentiate
between objects which are failing the comparison and objects which are considered equal but
have different outputs for inspect. One notable example is ActiveSupport::Duration where
60.minutes is considered equivalent to 1.hour, but produces different output for inspect
which can cause confusion and seem like it is failing the assertion when it is in fact just failing the
inspect comparison.
The proposal is to allow inspectors to be registered in ObjectFormatter so that custom
inspectors can be added for these classes, to improve the signal to noise ratio in diffs
when looking at failed tests.
At the moment it is possible to 'hack' this by manually prepending a custom inspector class
to RSpec::Support::ObjectFormatter::INSPECTOR_CLASSES, but here we create a more
friendly interface to allow this through something like:
RSpec::Support::ObjectFormatter.inspectors.register(CustomInspector)

If this gains enough traction this could be expanded to allow for configuring this in
RSpec's configuration, perhaps in a similar way to what is mentioned here.
Related to https://github.com/rspec/rspec-expectations/issues/97
Your environment

Ruby version: ruby 2.7.3p183
rspec-support version: 3.11.0.pre

Steps to reproduce
To see an example of failing specs which provide misleading diffs, run this example and
note how in the 'does not show in the diff when objects are equivalent' example it seems
that both object1 and object2 are failing the assertion, when in fact only object2
is failing the assertion.
begin
  require "bundler/inline"
rescue LoadError => e
  $stderr.puts "Bundler version 1.10 or later is required. Please update your Bundler"
  raise e
end

gemfile(true) do
  source "https://rubygems.org"

  gem "rspec", "3.10.0" # Activate the gem and version you are reporting the issue against.
end

puts "Ruby version is: #{RUBY_VERSION}"
require 'rspec/autorun'

class TimeParts
  SECONDS_PER_MINUTE = 60

  def initialize(minutes, seconds)
    @minutes = minutes
    @seconds = seconds
  end

  def to_i
    (@minutes * SECONDS_PER_MINUTE) + @seconds
  end

  def inspect
    "#{@minutes} minutes and #{@seconds} seconds"
  end

  def ==(other)
    self.to_i == other.to_i
  end

  alias_method :eql?, :==

  def hash
    [@minutes, @seconds].hash
  end
end

RSpec.describe TimeParts do
  it 'considers equavilent objects equal' do
    object1 = TimeParts.new(1, 30)
    object2 = TimeParts.new(0, 90)
    expect(object1).to eq(object2)
  end

  it 'does not show in the diff when objects have the same result from inspect' do
    hash1 = {
      object1: TimeParts.new(0, 90),
      object2: TimeParts.new(0, 90)
    }
    hash2 = {
      object1: TimeParts.new(0, 90),
      object2: TimeParts.new(1, 90)
    }
    expect(hash1).to eq(hash2)
  end

  it 'does not show in the diff when objects are equivalent' do
    hash1 = {
      object1: TimeParts.new(1, 30),
      object2: TimeParts.new(0, 90)
    }
    hash2 = {
      object1: TimeParts.new(0, 90),
      object2: TimeParts.new(1, 90)
    }
    expect(hash1).to eq(hash2)
  end
end

Expected behavior
We should be able to register a custom inspector, to be able to modify the output of inspect
for specific objects, so that it becomes easier to tell what is actually failing the assertion:
class TimePartsInspector < ObjectFormatter::BaseInspector
  def self.can_inspect?(object)
    TimeParts === object
  end

  def inspect
    object.to_i.inspect
  end
end

RSpec::Support::ObjectFormatter.inspectors.register(TimePartsInspector)

This would mean that after registering the custom inspector above, the diff would look like this:
Failure/Error: expect(hash1).to eq(hash2)

  expected: {:object1=>90, :object2=>150}
       got: {:object1=>90, :object2=>90}

  (compared using ==)

  Diff:
  @@ -1,3 +1,3 @@
   :object1 => 90,
  -:object2 => 150,
  +:object2 => 90,

Actual behavior
Diffs are based on the raw outoput of inspect, so it is hard to tell that the value in object1
is not actually failing the assertion, and that only the value in object2 is the issue:
Failure/Error: expect(hash1).to eq(hash2)

  expected: {:object1=>0 minutes and 90 seconds, :object2=>1 minutes and 90 seconds}
       got: {:object1=>1 minutes and 30 seconds, :object2=>0 minutes and 90 seconds}

  (compared using ==)

  Diff:
  @@ -1,3 +1,3 @@
  -:object1 => 0 minutes and 90 seconds,
  -:object2 => 1 minutes and 90 seconds,
  +:object1 => 1 minutes and 30 seconds,
  +:object2 => 0 minutes and 90 seconds,

What will diff output after this change?
  Diff:
  :object1 => 0 minutes and 90 seconds,
  -:object2 => 1 minutes and 90 seconds,
  +:object2 => 0 minutes and 90 seconds,

Related: https://github.com/rspec/rspec-support/issues/365

I love the idea.
Maybe we could specify in the failing output the custom inspector used?

@pirj , I've updated the expected behaviour section to clarify what the diff would look like after registering the new inspector. Hopefully that answers your question but let me know if it doesn't.
Note that the change here would not affect any diffs unless a new inspector is registered. It only makes it easier to add custom inspectors to allow for customization of diff output for certain objects.

@benoittgt can you clarify in terms of implementation what you have in mind? Are you thinking we should differentiate between custom inspectors and default ones (the ones currently in INSPECTOR_CLASSES) and concatenate something in the inspect itself to denote that the object was inspected with a custom inspector? E.g.:
  Diff:
  @@ -1,3 +1,3 @@
   :object1 => 90 (inspected with TimePartsInspector),
  -:object2 => 150 (inspected with TimePartsInspector),
  +:object2 => 90 (inspected with TimePartsInspector),

From what I understand of the code (and I could definitely be misunderstanding this), with the exception of arrays and hashes, currently it will always use an inspector to inspect any object, falling back to UninspectableObjectInspector and ultimately to InspectableObjectInspector if all else fails. So I believe we would need to differentiate between the default ones custom ones to avoid adding too much noise in the failing output?

@b-loyola yes that was exactly what I was thinking when I saw your example.

So I believe we would need to differentiate between the default ones custom ones to avoid adding too much noise in the failing output?

Yes completely. Only custom one could be "noisy" by default. I am worried about having future issues on RSpec with people that use invalid custom inspector but doesn't know it is used in diff.
But I think that first we should wait for @JonRowe feedbacks on your existing PR. ;)

There are two problems here.

Output is confusingly similar for equal objects
Would you consider different output for TimeParts#to_s and TimeParts#inspect? Like e.g. the beforementioned ActiveSupport::Duration does?

1.minute.to_s => "60"
60.seconds.to_s # => "60"
1.minute.inspect # => "1 minute"
60.seconds.inspect # => "60 seconds"

This wouldn't be a problem if:

see problem 2 below (for simple data structures)
we were showing good diffs for complicated structures (and using super_diff is an option)

Failure messages for Hashes and Arrays
Both are sub-par.

2.1 Hashes
     Failure/Error: it { expect({foo: 1.minute, bar: 1.minute}).to include(foo: 60.seconds, bar: 59.seconds) }

       expected {:bar => 1 minute, :foo => 1 minute} to include {:bar => 59 seconds}
       Diff:
       @@ -1,3 +1,3 @@
       -:bar => 59 seconds,
       -:foo => 60 seconds,
       +:bar => 1 minute,
       +:foo => 1 minute,

as you already mentioned, it's the diff that has a deficiency. Should have been:
{
  :foo => 60 seconds,
- :bar => 59 seconds,
+ :bar => 1 minute,
}

For comparison, super_diff's output:
         {
           foo: #<ActiveSupport::Duration:0x00007fd7a3e3d2f8 {
             @parts=nil,
             @value=60
           }>,
       -   bar: #<ActiveSupport::Duration:0x00007fd7a3e3cfd8 {
       -     @parts=nil,
       -     @value=59
       -   }>
       +   bar: #<ActiveSupport::Duration:0x00007fd7a3e3d208 {
       +     @parts=nil,
       +     @value=60
       +   }>
         }

A bit too verbose for my taste, but it doesn't suffer from either problems.
With or without require "super_diff/active_support" doesn't make a difference.
2.2 Arrays
     Failure/Error: it { expect([1.minute, 1.minute]).to contain_exactly(60.seconds, 59.seconds) }

       expected collection contained:  [59 seconds, 60 seconds]
       actual collection contained:    [1 minute, 1 minute]
       the missing elements were:      [59 seconds]
       the extra elements were:        [1 minute]

Surely, it would better look as
[
- 59 seconds,
+ 1 minute,
  60 seconds
]

For comparison, super_diff's output:
         [
           #<ActiveSupport::Duration:0x00007fd7a31c6c68 {
             @parts=nil,
             @value=60
           }>,
       +   #<ActiveSupport::Duration:0x00007fd7a31c6ba0 {
       +     @parts=nil,
       +     @value=60
       +   }>,
       -   #<ActiveSupport::Duration:0x00007fd7a31c6808 {
       -     @parts=nil,
       -     @value=59
       -   }>,
         ]

Again, quite verbose.
Speaking of custom inspectors, I'd love to highlight @benoittgt's concern:

use invalid custom inspector but doesn't know it is used in diff

The failure message output for eq/eql/equal/be matchers is identical, but their comparison is different. It might be surprising to see:
     Failure/Error: it { expect(1.minute).to equal(60.seconds) }

Diff:
- 60
+ 60

super_diff for example:
     Failure/Error: it { expect(1.minute).to equal 60.seconds }

       Expected #<ActiveSupport::Duration:0x00007fa69a55a030 @parts=nil, @value=60>
       to equal #<ActiveSupport::Duration:0x00007fa69a559f40 @parts=nil, @value=60>
     # /Users/pirj/.rvm/gems/ruby-2.7.2@cowboy-web/gems/super_diff-0.8.0/lib/super_diff/rspec/monkey_patches.rb:43:in `handle_failure'

And stock RSpec wins the race here:
       expected #<ActiveSupport::Duration:60840> => 60 seconds
            got #<ActiveSupport::Duration:60940> => 1 minute

       Compared using equal?, which compares object identity, but expected and actual are not the same object. Use
       `expect(actual).to eq(expected)` if you don't care about object identity in this example.

       Diff:
       @@ -1 +1 @@
       -60 seconds
       +1 minute

For those issues, custom differs could be an option, but it's quite a long way to catch up with super_diff [[1], [2]].

@benoittgt that makes sense. But I think a potential pitfall with appending a (inspected with CustomInspector) to custom inspector diffs directly in ObjectFormatter is that it a makes it more difficult to customize diff output when the objective is to make two objects from different classes which are considered equivalent to be displayed in the same way in diffs.
For example, let's say I want ActiveSupport::Duration to be inspected just like Integer since for most intents and purposes it behaves like an integer . That is, 1.hour == 3600 returns true so it would be nice to be able to customize durations to be inspected the same way as integers for failing specs output only. For example, currently if I write the following assertion:
hash1 = {
  travel_duration: 1.hour,
  meal_duration: 2.hours
}
hash2 = {
  travel_duration: 3600,
  meal_duration: 7000
}
expect(hash1).to eq(hash2)

it fails with:
     Failure/Error: expect(hash1).to eq(hash2)

       expected: {:meal_duration=>7000, :travel_duration=>3600}
            got: {:meal_duration=>2 hours, :travel_duration=>1 hour}

       (compared using ==)

       Diff:
       @@ -1,3 +1,3 @@
       -:meal_duration => 7000,
       -:travel_duration => 3600,
       +:meal_duration => 2 hours,
       +:travel_duration => 1 hour,

In this case, only meal_duration is failing the assertion, but travel_duration is appearing in the diff as well. If we appended a (inspected with DurationInspector) which is an inspector which can_inspect? only returns true to instances of ActiveSupport::Duration, then we still end up with a red herring for travel_duration in the diff:
       Diff:
       @@ -1,3 +1,3 @@
       -:meal_duration => 7000,
       -:travel_duration => 3600,
       +:meal_duration => 7200 (inspected with DurationInspector),
       +:travel_duration => 3600 (inspected with DurationInspector),

I think this means that to cover this case without bigger changes we'd need to use the same inspector for both ActiveSupport::Duration and Integer in order for these to now show up in the diff?
With that in mind I'd say that my opinion is that a note about which inspector was used probably doesn't belong in ObjectFormatter. It could probably be added somewhere else (maybe in the Differ?) so that it lists all custom inspectors used, but I'm not sure how much work that would be and how much scope it would add here.

@pirj thanks for the detailed feedback and all of the examples. I definitely agree and I wasn't really thinking of the object identity case here so I do see how that could be a potential pitfall.
That being said though, the objective here was just to provide a more friendly interface to customize object inspection for spec purposes only.
For instance, right now if I have an assertion which compares hashes where all the values are instances of ActiveSupport::Duration, it can become difficult to tell what is failing the assertion. This is because inspect for these objects really doesn't convey the true nature of the information which they represent (number of seconds as an integer):
(2.hours - 60.minutes) == 1.hour
#=> true
(2.hours - 60.minutes) == 3600
#=> true
(2.hours - 60.minutes).inspect
#=> "2 hours and -60 minutes"
1.hour.inspect
#=> "1 hour"
3600.inspect
#=> "3600"

So adding the ability to register a custom inspector is really just a way to enable a custom representation of an object for spec comparisons only (without the need to monkey-patch a class' #inspect in a spec helper), if there is a wish to do so.
As mentioned in the description this is actually currently possible to do as a "hack", by prepending a custom inspector to INSPECTOR_CLASSES, like this:
RSpec::Support::ObjectFormatter::INSPECTOR_CLASSES.unshift(MyCustomInspector)

So the main goal of this PR is just to make this a better interface and potentially open up a path forward to do something like what is mentioned here, e.g.:
RSpec.configure do |config|
  config.inspectors.register(MyCustomInspectorForDuration)
  config.inspectors.register(MyCustomInspectorForSomeOtherObject)
  # etc
end

From my (rather subjective and opinionated) point of view, objects should adhere to some protocol that consumers can rely on. In this case, it's "return the internal representation for inspect that is helpful in development, return business representation for to_s, for runtime". And ActiveSupport::Duration does its job very well on this front.
Unfortunately, Ruby is not so formalized as other languages, and this statement has no reinforcement I know of.
I'm personally reluctant to decorate objects for diffing purposes, especially if it seems possible to keep the presentation under control by adhering to the above rule. Given that the differ is matcher-aware and doesn't solely rely on the a.inspect == b.inspect.
In any case, the specs are too specific and don't indicate clearly what the difference custom inspectors make. I would ask to add more specs, but don't really want to waste your time.
If you are dedicated to improve differ's output, I'd suggest improving the output for Hash/Array, for cases described above.
It's a sensitive topic, though, since various CI/IDEs relying on the current output format.

Thanks @pirj that's great feedback. While I agree with your opinion that objects should adhere to some protocol that consumers can rely on, my opinion is that it's not easy (if at all possible) to keep the presentation under control just by adhering to the protocol mentioned above. In fact, the ActiveSupport::Duration object is a great example where that protocol is followed but the Differ and ObjectFormatter currently don't do a great job in presenting the differences because it's not easy to do so. Even if it was possible though, there are probably countless codebases with with objects that don't follow this pattern out there, and I'd be reluctant to implement something that assumes all objects follow that protocol and end up with a worse presentation than what is currently done.
From my (also very subjective and opinionated) point of view, it's better to allow users to customize the output to be the way they want it for specific objects than to introduce breaking changes in presentation that assume that an object should be sometimes presented with inspect and sometimes presented with some other method (e.g. to_s), which I think could be more confusing.
In a separate point, I checked what the differ does with regards to the object identity and it seems to handle that case pretty well since it shows that they are different objects:
       expected #<ActiveSupport::Duration:16960> => 90 seconds
            got #<ActiveSupport::Duration:16980> => 90 seconds

       Compared using equal?, which compares object identity,
       but expected and actual are not the same object. Use
       `expect(actual).to eq(expected)` if you don't care about
       object identity in this example.

This would still be pretty readable with the custom inspector:
       expected #<ActiveSupport::Duration:16960> => 90
            got #<ActiveSupport::Duration:16980> => 90

       Compared using equal?, which compares object identity,
       but expected and actual are not the same object. Use
       `expect(actual).to eq(expected)` if you don't care about
       object identity in this example.

Anyway, I'm happy to add more test cases here if that will help push this forward, but also don't want to waste more time if  this is not going to be considered. In my opinion, while this is definitely not a complete solution it's a step in the right direction. If there's disagreement there then there's probably no point in continuing to work on this, but if we agree that this can provide value then I can definitely add more tests here. If that's the case just let me know what kind of specs you would like to see here.

@b-loyola One more example I can think of.
expect(state_change_margins).to eq([0.celsius, 100.celsius]) # celsius

   expected collection contained:  [0'C, 100'C] (inspected with TemperatureInspector)
   actual collection contained:    [-10, 100]

Should there only be just one base representation for inspection in diff? What if the object is comparable with an integer (`100`) and a string (`100 F`), should we inspect is as a string, or as an integer?

Personally, I'm not convinced by the idea. However, my opinion counts last, as I have the least experience with differs code.
Let's see what @benoittgt and @JonRowe think.

should we inspect is as a string, or as an integer?

@pirj that's kind of my point here. I don't think it's rspec's job to know how to represent every object out there, and allowing different codebases to customize how to represent objects for only for  diffing purposes is what this PR is all about (or at least paving way for doing so). If in one codebase there is an object which is usually compared with integers, registering a custom inspector for that object to be displayed as an integer might make sense. If in another codebase there's an object that is usually compared to strings, there might be a desire to customize how that object is inspected for diffing. And in most cases they will probably just want what the default behaviour is, and let the representation just follow what inspect for the object returns - that's fine too, nothing changes in this case - if an inspector is not registered there would be no changes to this behaviour.
And to voice my (again subjective) opinion here, while I know this is possible I kind of disagree with the idea of an object that can be both equal to 100 (integer) and "100'C"(string) because - and maybe javascript developers will disagree with this - to me it doesn't make sense for an object to be equal to both an integer and a string, specially when the string an integer will not equal each other. However, I don't think any of this is in the scope of the change proposed here - these cases are very hard to deal with and I'd say the rspec differ probably doesn't need to support that. If you really wanted to support this though, someone could propose it in a separate PR - the change proposed here is not mutually exclusive with that.

Is it possible to achieve something similar and file-local via refinements?
Not sure where to put "using" though.
Below did not work
module Inspection
  refine Whatever do
    def inspect
      "custom inspection"
    end
  end
end

# ObjectFormatter is the class that send "inspect" to Whatever's – I'm assuming it should pull the refinement?
RSpec::Support::ObjectFormatter.class_exec do
  using Inspection
end

describe Whatever do
  using Inspection
  example do
    puts Whatever.new.inspect # => "custom inspection"
    expect([]).to include(Whatever.new) # => generic ... expected [#<Whatever x: nil>] got [] ...
  end
end

https://github.com/halostatue/diff-lcs/issues/70 semi-related

Closing as this is probably stale now, can reopen if there's any interest.


please add chinese

Chinese is already available.
 |

But it is not Chinese

It's associated with the localization code zh_CN which is Chinese Simplified.
What type of Chinese language are you referring?

chinese simple

If Language is set to Chinese Simplified, everything stays in English. If it's set to System, only the publishing time of tweets become Chinese Traditional.

Besides, transtation to Chinese is not avaliabe. Is it supprted by APIs?

Squawker is supposed to be translated to Chinese (simplified) for 97% of its strings, as you can see in the Squawker's translation site.
But you're right, in Squawker selecting Chinese (simplified) does nothing. The app stays in English. This is a bug. That you for pointing that out. I'll look into it.
By the way I noticed that the same problem also exists for some other languages, like Español for instance.

There is a bug with the internationalization tooling in Flutter when it comes to locales with script codes.
Specifying the locale zh_Hans (language: zh (Chinese), script code: Hans (Simplified)) do not work correctly in Flutter, although it should.
Instead I could use the locale zh_CN (language: zh (Chinese), country: CN (China)) which could reflect about the same thing (maybe?), and in which case it works properly in Flutter.
Not ideal I guess but does it seem a good workaround?

This is now resolved witch version 3.7.0.