anon-iclr-submission/benchname-bug-localization huggingface dataset:
Repository: greenmail-mail-test/greenmail
Issue: Greenmail SMTP server doesn't handle periods correctly

Per http://tools.ietf.org/html/rfc5321#section-4.5.2 :

> ```
>  When a line of mail text is received by the SMTP server, it checks
>  the line.  If the line is composed of a single period, it is
>  treated as the end of mail indicator.  If the first character is a
>  period and there are other characters on the line, the first
>  character is deleted.
> ```

`com.icegreen.greenmail.mail.MovingMessage#readDotTerminatedContent` handles the the case of a line containing a single period, but does not handle the case where a line starts with a period and there are other characters.

The end result is mail sent to Greenmail's SMTP server can contain extra periods when retrieved via IMAP or POP3.


Changed files:
greenmail-core/src/test/java/com/icegreen/greenmail/test/SmtpServerTest.java, greenmail-core/src/main/java/com/icegreen/greenmail/mail/MovingMessage.java

diff --git a/greenmail-core/src/main/java/com/icegreen/greenmail/mail/MovingMessage.java b/greenmail-core/src/main/java/com/icegreen/greenmail/mail/MovingMessage.java
index 03e6a64e..fbbfd15d 100644
--- a/greenmail-core/src/main/java/com/icegreen/greenmail/mail/MovingMessage.java
+++ b/greenmail-core/src/main/java/com/icegreen/greenmail/mail/MovingMessage.java
@@ -110,6 +110,8 @@ public class MovingMessage {
                 dataWriter.close();
 
                 break;
+            } else if (line.startsWith(".")) {
+                dataWriter.println(line.substring(1));
             } else {
                 dataWriter.println(line);
             }
diff --git a/greenmail-core/src/test/java/com/icegreen/greenmail/test/SmtpServerTest.java b/greenmail-core/src/test/java/com/icegreen/greenmail/test/SmtpServerTest.java
index c56b6f79..8a4b89f5 100644
--- a/greenmail-core/src/test/java/com/icegreen/greenmail/test/SmtpServerTest.java
+++ b/greenmail-core/src/test/java/com/icegreen/greenmail/test/SmtpServerTest.java
@@ -128,4 +128,14 @@ public class SmtpServerTest {
             assertEquals(i, gif[i]);
         }
     }
+
+    @Test
+    public void testSmtpServerLeadingPeriods() throws MessagingException {
+        String body = ". body with leading period";
+        GreenMailUtil.sendTextEmailTest("to@localhost.com", "from@localhost.com", "subject", body);
+        MimeMessage[] emails = greenMail.getReceivedMessages();
+        assertEquals(1, emails.length);
+        assertEquals("subject", emails[0].getSubject());
+        assertEquals(body, GreenMailUtil.getBody(emails[0]));
+    }
 }
Repository: foundationdb/fdb-record-layer
Issue: FilterCursors can shuffle off work to the wrong executor

The `whileTrue` loop in `FilterCursor` does not set an executor:

https://github.com/FoundationDB/fdb-record-layer/blob/f2b43c13b39ba9bb9aa9e79174afdade3d62db00/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/cursors/FilterCursor.java#L68-L72

This means that if there are any asynchronous callbacks, they will be scheduled on the `ForkJoinPool.commonPool()` even if the user has specified a specific executor to use.

Changed files:
fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/cursors/FilterCursor.java
fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/keyspace/ResolverMappingReplicator.java

diff --git a/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/cursors/FilterCursor.java b/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/cursors/FilterCursor.java
index 1a5f32d4..63c40013 100644
--- a/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/cursors/FilterCursor.java
+++ b/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/cursors/FilterCursor.java
@@ -69,7 +69,7 @@ public class FilterCursor<T> implements RecordCursor<T> {
             nextResult = innerResult;
             hasNext = innerResult.hasNext() && (Boolean.TRUE.equals(pred.apply(innerResult.get()))); // relies on short circuiting
             return innerResult.hasNext() && !hasNext; // keep looping only if we might find more records and we filtered a record out
-        })).thenApply(vignore -> {
+        }), getExecutor()).thenApply(vignore -> {
             mayGetContinuation = !hasNext;
             return nextResult;
         });
diff --git a/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/keyspace/ResolverMappingReplicator.java b/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/keyspace/ResolverMappingReplicator.java
index f8477455..91e82a48 100644
--- a/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/keyspace/ResolverMappingReplicator.java
+++ b/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/keyspace/ResolverMappingReplicator.java
@@ -155,7 +155,7 @@ public class ResolverMappingReplicator implements AutoCloseable {
                 .whenComplete((vignore, eignore) -> cursor.close())
                 .thenApply(vignore -> Objects.nonNull(continuation.get()));
             });
-        });
+        }, runner.getExecutor());
     }
 
     @Override